CERNLIB (x86-64) Page of Harald Vogt

64-bit CERNLIB (release 2005)
for AMD64/Intel® EM64T (x86_64) architectures

Harald Vogt

Deutsches Elektronensynchrotron

The content of this page is obsolete !!!
see now http://www-zeuthen.desy.de/linear_collider/cernlib/new/cernlib_2005.html

Most of the links are not supported anymore!
It is still present for historical reasons.

Wed Jun 7, 2006: CERNLIB 2005 using gfortran

Newer versions of gcc4/gfortran (e.g. gcc version 4.2-20060520 or higher) require a different handling of the fortran intrinsic getarg. Therefore the code of ./2005/src/packlib/kernlib/kerngen/tcgen/lnxgfort/getarg.F was changed.

Wed May 24, 2006: 64-bit CERNLIB 2005 installation - bug corrected

The bug was related to the code in ./2005/src/pawlib/paw/ntuple/qp_execute.c and is corrected now. It comes up if using "nt/pl 10.function(x)" where function(x) is defined in an "application comis".
The download files cernlib.2005.corr.tgz and cernlib-2005-all.tgz are updated.

Mon May 22, 2006: 64-bit CERNLIB 2005 installation - bug corrected

The bug was related to the code in ./2005/src/pawlib/comis/code/ (cskcal.F and csintx.F) and is corrected now.

Tue Apr 11, 2006: 64-bit CERNLIB 2005 installation reorganised

This release should compile and run on 32-bit/i386 and 64-bit/x86_64 architectures.
For 64-bit architectures the following compiler option has been added:
-fPIC (required for ROOT's cernlib components)
For gcc3/g77 on 64-bit architectures an additional compiler option must be added:
-fno-f2c (according to the gcc compiler bug report 15397 for AMD64).

Remark:
The usage of the g77's -fno-f2c option requires for an application using cernlib that all Fortran source files and also those for private libraries used have to be compiled using this option as far as the following is taken into account:
The -fno-f2c option changes the ABI only for function calls (REAL, DOUBLE, COMPLEX).
If a "cernlib application" uses such functions from additional packages these packages have to be compiled with the -fno-f2c option.
To avoid the special compiler option -fno-f2c with g77 I have investigated a solution using gfortran.

A good reference for the application programmer for AMD64/EM64T architectures (also called x86_64 architectures) is the System V Application Binary Interface (AMD64 Architecture Processor Supplement) draft.

What is essential for porting CERNLIB to x86_64 architectures is written there in chapter 3.3.4 (Virtual Address Assignments). Code segments start at low memory address (0x400000) and data segments follow direct after code segments.
This means there is a good chance that all cernlib code can be adapted to 64 bit because the addresses of the routines and of the COMMON areas used are in the 32 bit address space. Problems may arise if an user application based on cernlibs ZEBRA memory manager exceeds this address space (huge COMMON areas). The reason for cernlibs limitation on 64 bit architectures results from the fact that pointers which are used in ZEBRA are stored as INTEGERS (4 bytes) whereas pointers on x86_64 architectures require in general 8 bytes. Therefore special care is needed concerning the pointer handling in the cernlib code.

Installations:
I have checked this release of cernlib on on 32-bit/i386 and 64-bit/x86_64 architectures with Scientific Linux 3/4 and gcc compiler versions 3.2.3/3.4.3/4.2(experimental). It passes all packlib tests and paw (paw++) demo tests.
Starting with the original cernlib 2005 code I put my modifications to this distribution in a separate zipped tar file .
To enable a complete cernlib installation the LAPACK and patchy4 sources and additional install scripts have been included in this zipped tar file .
The following is needed:

download cernlib-2005-all.tgz to your installation directory
run "gtar -zxf cernlib-2005-all.tgz
run "./Install_cernlib"

This installs
the blas and lapack libraries in the LAPACK subdirectory,
the patchy4 executables in the patchy subdirectory,
and in the ./2005 directory tree all cernlib sources, libraries, and executables.

Special Remark:
A critical point in the comis part of cernlib is the dynamic linking of external Fortran/C routines which are loaded from a shared library created. This may and will result in jump addresses larger the 32 bit and requires the introduction of INTEGER*8 handling in the Fortran code of the 2005/src/pawlib/comis/code directory.
This is needed since the function pointers given as 1st argument to the C functions cscali, cscalr, and cscald in the 2005/src/pawlib/comis/deccc directory must be of type long (8 Bytes).

Details:

csinit.F:		the -fPIC and the -fno-f2c compiler option is needed for shared objects, initialisation for INTEGER*8 pointer array
csaddr.F, cslink.F:		the jump address to the shared object obtained by CS_GET_FUNC() is of type long and must be taken as INTEGER8 and has to be saved in an INTEGER8 array
csitgpl.F, csrtgpl.F:		new utilities to provide the INTEGER*8 array usage
csintx.F, cskcal.F:		take the jump addresses for calls to cscali, cscalr, and cscald from the INTEGER8 array if they are derived from dynamic linking. For all other cases the jump addresses are taken from INTEGER4 values and stored in an INTEGER*8 value.

CERNLIB version 2005 installation with gfortran
To avoid the special compiler option -fno-f2c with g77 I have investigated a solution using gfortran.
The modifications are backward compatible and can be used also with GCC3/g77.
But gcc4(gfortran) is still developing fast and some problems with the compiler suite had to be solved to enable a cernlib installation. The compiler version used was taken from GCC Snapshots selecting 4.2-20060128 or choose one of its mirrors for downloading. The corresponding Status Report is here. The quality of this snapshot seems to be good enough to use it for a CERNLIB installation.

One problem is that the functions csqrt, csqrtf, csqrtl of libm (glibc) which are used by gcc4 are still buggy for x86_64 architectures:
see http://sources.redhat.com/bugzilla/show_bug.cgi?id=2181 (2182)
Concerning CERNLIB this will cause a failure in the MATHLIB's C208 test for the RTEQ4, DRETQ4 routines.
To solve this I have the modifications not included it in my CERNLIB distribution because it will depend on the future of gfortran and glibc. Therefore I provide:

a piece of C-code (derived from gcc4's c99_functions.c) which has to be compiled separately.
After the CERNLIB installation the object file csqrt.o has to be copied to ./2005/lib
a modified cernlib script which has to replace ./2005/bin/cernlib

A second problem when using gfortran on x86_64 architectures is that the processor can distinguish between positive and negative real zero.
Gfortran aims to be Fortran ISO standard 2003 compliant and will take into account what is said in subsection 1.6.1 of the J3/03-007R2 Final Draft. Therefore for some functions (atan2, log, and sqrt) with complex arguments a different behaviour compared to g77 (gcc3)) may be observed. This requires a specific modification of CERNLIB's C207 routine rteq464.F .

created: Tue Apr 11, 2005
last updated: Tue Dec 12, 2006
old webpage
H. Vogt

64-bit CERNLIB (release 2005) for AMD64/Intel® EM64T (x86_64) architectures