Compiling the GENSER_1_3_0 packages , using the G95 & GFC compilers. ----------------------------------1/7/06--- Introduction ------------ By mid 2005 the GNU organization had announced the withdrawll of it's support to the g77 compiler. CERN and the HEP communities got worried ,since the huge Fortran legacy of GEANT3,FLUKA and GENSER packages ,had to be looked after for some quite long time in the future. Last summer (2005), I was requested to examine the available Compilers candidates: G95 GFORTRAN LAHEY-FUJITSU The first two, had survived a NASA test:The only 2 out of 12 compilers which didn't CRASH on it. The 3-rd, was strongly, recommended by the Accelartor group at Cern, but it failed on some ALICE code ! It's preprocessor couldn't handle some include files !! So we complained about it to the Company, but haven't heard from them ever since. We tested G95 and GFORTRAN on all the CERNLIB components and compared the following 3 issues: 1)The backward compatability to the g77 compiler. 2)Robustness to RUNTIME failures 3)The support from the authors. We summarize our findings in the next table -------------------------------------------------------------------------- The Issue | G95 | GFORTRAN -------------------|--------------------------|--------------------------- | | Author/s | 1 man's job | A group of GNU members+ | | Red-Hat 1 man's support --------------------| -------------------------|------------------------- Response time | Excellent ! ! Cumbersome for GNU to complaints | New release in 12 hrs | Faster for RH (few days) --------------------|--------------------------|------------------------- Adhering to the | Very strictly ! | More flexible X3J3 stds | | More extensions --------------------|--------------------------|------------------------- Sensetivity to | Not at all | Very sensetive to obsolete code. | | complicated structures --------------------|--------------------------|------------------------- My Grading | 90% | 80% --------------------|--------------------------|------------------------- GENSER code | Adequate | Less Compilation errors | | But more Run-time troubles ------------------------------------------------------------------------- Now to GENSER: Problems encountered with the GENSER code: [I] Most of the minor issues, were encountered already when we compiled the CERNLIBs.: Things like: a) The G95 requires a single SAVE statement in a routine, it can't tolerate the situation in which a specific SAVE variables appears in code , and a blank SAVE simulataneously. e.g: save a,b,c | Not-allowed in save | the same routine. b) Type declaration, can't be mixed with DATA statements ,in the same expression , unless one uses the new concept for it. (See the F95 books or manual). It means that : Integer ifirst /0/ Isn't allowed ! It has to be split into 2 lines: Integer ifirst data ifirst/0/ c) Loop variables ,can't be anything else ,but Scalar Integers ! We can't loop ,directly, on Real quantities. The integers can't be arrays,they must be declared Scalar entities. In the same token, REAL indecies to arrays and Matirces aren't recognized by the G95 compiler. The following loop structures aren't allowed: do iq=8,13. ...... enddo or do 0.1,1.0,0.1 ....... enddo or do i=1,k(someindex) ..... enddo d) Open(unit...,NAME=filename,... ) ----> Open(unit,..FILE=filename,..) The g77 tolerates both forms, the G95 and GFC dont !. e) A "$" descriptor in a printing format,must be the last specifier in the format , e.g: 301 format(3x,1P,e16.8,0P,i4,$,3i10) --> Isn't accepted by g95 & GFC 301 format(3x,1P,e16.8,0P,i4,3i10,$) --> Is accepted " " " ! [II] New major issues: ---------------- a) A new issue was encountered in the GENSER packages, it's related to the fact that some of the code was generated by MAthematica package. Which ,apparently, can produce code which is compatible with Fortran-77 standards,some of which aren't accepted by the G95 compiler, since it violates the lowest level of basic definition of the Fortran expression. This is the issue of using 2 consecutive pluses or minuses signs in 1 Fortran expression. e.g: let (C),and (D) be any Fortran expression, then the following expressions could be seen,emerging from Mathematica: A= (C) + + (D) or A = (C) - - (D) We,actually see ,such code, in 2 Generators (Isajet & Feynhiggs). In one case it had so many "corrupted" lines ,that we had to come up with an elaborate SED script to fix it. The 2 signs were split in many cases between 2 lines of code , the first + at the end of the first line ,and the 2-nd + at the beginning of the next line (after the continuation character !) . Finally, after complainning about it ,to the Originators of the code, they said, Aah! , the next release doesn't have it anymore !!! But still, some other generator has it, in very small numbers , so the issue exists and should be taken care of. The remedy we used: In the case of 2 + signs ---> We have to drop one of them. In the case of 2 - signs ---> We have to replace the 2 - with 1 + !!! Another issue ,related to Mathematica, is also the fact, that the length of the sources lines is no longer the "sacred" 80 characters/line, but could run up to 132 or maybe more ! (Depending who produces the code ) Hence it compells us to use for both compilers the Compiler option which allows for it. Namely: -ffixed-length-line-132 for both compilers. !!! (see further down for the other options used) b) The issue of COMPLEX*16 function's name convention: The g95+GFC accept only the form: complex*16 function name (,,,) And the g77 acceptes this form : comlpex function name*16 (,,,) and the previous one as well. Hence ,adapting the first form ,wouldn't cause any damage to g77 versions !!! c) In RUN-TIME ,it was found that g77 can read List-Directed input ,in very "strange" ways. According to the F77 library books, it reads the List Directed items, when they are separated from each other, either by a comma or by blanks (1 or more). We found that files could be read in LIST-DIRECTED mode, without any blank or Comma !!!! Apparantly, it could be done, if the items are in decimal form and the Dot and or exponents exist, then it's separable !!! But that ,obviously, ISN'T ACCEPTED by the G95 run-time library !! And " " " " GFC as well !! We had to go thru few files , and insert blanks and or commas to separate the items. In particular, the "scheme"'s favorite finding is in fact, that the Minus sign could be used as a separator between Decimal numbers in form of 0.xxxxE-yy, the minus sign of the next number is used as a separator . As is seen in lines like: 0.12345D+01-123.456 or 0.12345D-05-0.98765D-12 etc... One should insert a space or a comma---------^ (See the PDFSETs of lhapdf ) A unique issue to GFC, is the Extra Apostroh issue ! When data lines contain strings items. these strings are embeded in a pair of Apostrohes. If for some reason, an extra apostroph is inserted into the string , as part of the string,it's a GFC's run-time error ! More over, if one Apostroph is missing, or both, it's disastertous !! The result of the above could be summarized in: Genrators table after applying G95 compiler, and the GFC compiler (By end of July 2006) ------------------------------------------------ ----------------|--------------|---------------|------------------|------- Generator | G95 Compil | Testing | Comments | GFC name | errors | issues | |behav ----------------|--------------|---------------|------------------|------- 1)Pythia | None | OK | Smooth process | None 2)Herwig | " | " | " " | Runt 3)Isajet | 2 Minor | needed some | After the fixing | v | 1 Major(++) | fixing in | it ran smoothly | v | 1 Runtime | prtlim.f | | Runt | | | | 4)PHOTOS | None | OK | S.p | None 5)Hijing | None | OK | S.p | " 6)Jimmy | 2 minor | OK | S.p | v 7)Phojet | 1 minor | OK | S.p | v 8)TopRex | 2 major+mino | OK | S.p | minor 9)Tauola | 1 minor + | OK | S.p | "bug" | a "bug" | | | F 10)Cascade | None | 1 link issue | Some i/o problems| F | | 1 Runtime | S.p after fixup | F | | (I/O) | | 11)Charybdis | None | OK | S.p | None 12)Feynhiggs | Many major | Ok | S.p after fixup | v 13} " 2_41 | None | OK | S.p | 14)Stagen | None | Ok | S.p | None 15)lhapdf | None | Minor+Read- | S.p after fixup | New | | list-direct | | F 16)Pyquen | None | OK | S.p | None 17)Hydjet | None | Ok | S.p | " 18)Alpgen |8 minors+3opn | Ok | S.p |3 opens * 19)madgraph | 1 minor +2 | -- | S.p | F + ** 20)mcatnlo | 7 minor | -- | Not tested |Open+Idate *** ----------------------------------------------------------------------- Meanning of symbols: v ---> In the last column, neans that ,the GFC compiler , hasn't failed on the same error as the G95 . F means ---> Found the same problems New " ---> New problems were encountered Runt ---> Run-time problems * ---> Compiler error ! (See below) The following list ,provides more details about the various issues, which were encountered in the various generators . The numbers correspond to the above numbers in the table. 2) A minor run-time issue, was encountered when GFC was trying to close a CLOSED already file (See herwig/examples/herwig65_ssy.f) !!! 3) 2 "improper" DO loop variables were rejected 1 "A=(B)+ +(C)" issue. G95 can't handle 2 consecutive Pluses !! 1 Runtime issue: Printing a logical var using Integer descriotor. (See subr prtlim.f) It happens with both, G95 and GFC as well ! 6) 2 minors: A Dual SAVE in genpnt.f An implicit J (REAL*8) is used as an index ! In subr jmdbska.f 7) 1 spurious SAVE line issue. 8) 1 "A=(B)- - (C)" issue . G95 can't handle 2 consecutive Minuses !! 1 "A=(B)+ +(C)" issue. The "++" issue. (The GFC ignores it!) The minor issues ,have to do with few files ,which their 1-st line contains some unprintable character (on my display it looks ^L, which could be a reminder from Microsoft handling ?) 9) 1 Mixed Declaration & Data (Integer ifirst /0/) 1 "Bug" --> Wrong type in calling sequence to In-line function Real*4 instead of Real*8 !! (Found by GFC as well) GFC stops when trying to Close a closed ,already,file. 10) a) While linking the examples, a reference to a missing External was detected (we dropped the ref to DGRV_NL) b) While Reading format('string',some descriptors) And the data line contains that string as first entity, it can't be read by the G95 ! ,it has to be replaced with nX ,where n is the width of the string. (This issue also occurs with GFC !!) 12-13) Original version of feynhiggs/2_2_10 had many "++" issues !!! (in 19 subroutines, tens of lines in each routine) When we notified the authors, it turned out,that they have a latest version 2_41 ,in which these issues no longer exist ! 15) When compiling the examples, we found do x=0.1,0.95,0.1 which isn't allowed by G95 1 test: (lhapdf_file.f) fails in reading few of the PDFSETs files ,the reason being : The Reading of List-directed files, (READ (unit,*)var1,var2,.......) encounters NO separators between some of the decimal quantities, which are being read in !!!! The G95 requires 1 of the 2 separators : blank or comma It can't resolve the unseparated decimals!!!! WHen GFC was applied,beside the previous issue and the Apostroph, a new issue came up: BEST=9.0e99 for BEST being REAL*8 type, A failure is declared ,since 9.0e99 exceeds the real*4 maximum value by huge amount (around 10**38 is maximum value !) hence one has to use BEST=9.0D99 instead, since 10**308 is the maximum allowed value !! 18) 8 cases of Dual declaration with Data (Only under G95) 3 cases of the OPEN ( NAME='filename' were used,. [For both comp] instead of: File='filename' *) A GFC Compiler BUG was found,in alplib/alppdf.f in subroutine cteq5 It's was seen already by 2 people and reported within the BUGZILLA mechanism. It has to do with gfc_trans_auto_array_allocation ! It occurs only when -fno-automatic option is used !!!!! See the 4 lines of code : subroutine bar(n) integer n,x(n) x(1)=0 end The Compiler prints:Compiler error in line 2 Internal compiler error in gfc_trans_auto_array_allocation at fortran/trans-array.c:3593 Please submit a full bug report... 19) The GFc finds few other inconsistencies, like in: madevent/Source/dsample.f ,a max function is used with real,integer) it should be all real args, The other "minor" issues for both compilres are: 1 Open ( NAME='filename' issue in Source/hcurve.f 3 COMPLEX functione name*16 instead of COMPLEX*16 .... in subr madevent/Source/hdecay.f In src/colors.f and leshouche.f we have $ misplaced in a middle of a format , and not at the end of it. **) Another GFC error was encountered in Madgraph/madevent/Source/decay.f a DREAL(nfound/nevent) is being used in a write(*,*) statement. The GFC complains that the argument has a wrong type, it should be complex(8) and not integer(4) !!? More over, to me it looks as an error, DREAL(n1/n2)*100d0 , If n2>n1 that'll always be = ZERO !!! , it should be (dble(n1)/dble(n2))*100d0 to produce precentage <=100% .. This issue, might not be due to Compiler bugs, but due to taking the standards very strictly. Looking in GFC web page,the DREAL(Z) is used only for Z being Complex(8), and it produces the real part of a complex number. The other compilers are treating DREAL as Alias to the DBLE(args), intrinsic function, in which the "args" could be of all types The G95 has also a problem with DREAL, which was reported. (20/8/06) And a new release was installed next day, which had the problem fixed !!!! 20) 7 calls to OPEN(...NAME..) has to be replaced with OPEN(...FILE=...) For both Compilers. Some part of the code is using IDATE(iday.imon.iyear), to get the date of the runnig. But the g77 & GFC compilers are using that name for their intrinsic function IDATE(intgerarray_of_3) and the conflict is reported in compile time !! ***) The same Compiler Bug which appears for Alpgen, is detected in mcatnlo_libofpdf.f as well. It's using a similar package of code. see *) [iii] G95 Compiler's options used: ---------------------------- g95 -c -w -fstatic -ffixed-line-length-132 -fsloppy-char -w --> Is essential to be used,otherwises you are flooded with lot's of warnings. -fstatic --> is the same as g77's -fno-aoutomatic (saving the local variables), it's neccssary for some generators !! -fsloppy-char -->Prevents type checks when printing formatted characters variables (It isn't really needed,but since it was used for the Cernlibs, we left it here, as well). -ffixed-line-length-132 --> 132 characters line width in fixed mode. Takes care of long lines structures. -fzero Equivalent to -finit-local-zero (of g77) (Initialize numeric types to zero & logicals to false) Found to be important to some Alpgen packages. [-g] for debugging [-fbounds-check] for index checking iv) Gfortran's options used: ------------------------ gfc -c -w -fno-automatic -ffixed-line-length-132 -frecord-marker=4 The new option is related to Reading Unformatted files,which were written by the g77 compiler ! For some reason, the Compiler's default for the internal record length was set for the Itanium machines,namely 64 bits , and we have to restore it to 32 bits long (4 bytes), otherwise many Lhapds tests wouldn't be able to run !!. V) Our recommendations to the GENSER community: -------------------------------------------- 1) Download G95 and/or GFC 2) Compile your latest version 3) Use the options, recommended above 4) Fix the compilation errors. 5) Run the tests and Compare ! 6) Make a new release ,or use Conditional Macros. 7) If you get Compilation errors that you can't fix, or the Compiler CRASHes while it compiles, write to Mr. Andy Vaught . 8) If you get RUNTIME errors which you can't overcome, or the results disagree significantly, a) Build a debug-library (-g) and use the GDB to trace the troubles, b) Please send me a copy of conditions at which it took place. (My E-mail : Refael.yaari@cern.ch ) I'll send out to the various authors , a short Memo,which describes the problems and the corrections which we have made to their codes. VI) A quick comparison between G95 and GFortran: ------------------------------------------- Most of the minor issues found by the G95 are processed thru by the GFC compiler without any complaint ! The ++/-- issue isn't an issue at all Dual Save, and Mixed Declaration with Data are processed thru. But: The List-READ_Direct issue, is also recognized. The extra apostrop issue ,is unique to GFC. Trying to close a closed file is also unique to GFC. The reading a string in the format, is also recognized The OPEN ( NAME='filename' is also recognized Wrong arg type for in-line function is caught. Idate is an intrinsic function, which is called with an integer array (of dimension 3) , the old 3 args variant, isn't recognized by g77 either. The g95 has it's own variant fdate(string) ! The issue of DREAL, is unique to GFC. And finally, their Bug (when the -fn-aotomatic is used) isn't a comforting blow, but there ways around it. The compilation time as compared to G95 is almost always,shorter and compared to G77 always longer ! There is 1 case in which GFC is by factor 10 slower than g77 !! That's with feynhiggs package, In which many routines have very long statements (MATHEMATICA's output) As you can see, I haven't touched the relative performace and the usage of Optimization levels. I feel that is little premature, but at some time should be tackled. I think,that still, both compilers can play an important role for the HEP community in the following years. Sincereley, Rafi Yaari.