[SciPy-dev] Scipy vs. Fedora Core 4

[Stephen Walton]

In late June, in this message:

http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2005-June/003041.html

Ravikiran Rajagopal posted a patch to 
scipy_core/scipy_distutils/gnufcompiler.py to cause it to use gfortran 
if it was available, as well as some patches to routines in 
scipy/Lib/linalg to get them to compile with gfortran.  In a followup 
message in mid August, he also suggested building ATLAS by changing 
'g77' to 'gfortran' in Make.Linux_ARCH.  I have a few comments and 
questions, after successfully building scipy on FC4 with the latest 
versions of gfortran and gcc 4, and using the patches Ravi posted on my 
copy of scipy (up to date from subversion as of today, which is to say 
scipy_core revision 986, scipy revision 1269).

In addition to changing 'g77' to 'gfortran' in ATLAS's Make.Linux_ARCH, 
one also has to add '-ff2c' to the Fortran compilation switches.  The 
reason is that ATLAS's setup procedure uses g77 to determine the Fortran 
to C calling conventions, but these conventions are different in 
gfortran.  'gfortran -ff2c' forces gfortran to be compatible with g77, 
which works the same as the old f2c command in this regard.  In 
particular, -ff2c causes external Fortran names which contain embedded 
underscores to have two underscores appended;  gfortran's default 
behavior is to only append one underscore to all external Fortran 
routine names.  I believe it's OK to do this with atlas without 
requiring -ff2c to be used systemwide, as the only ATLAS routine names 
which are exposed to the outside world do not have embedded underscores 
in their names and therefore have only a single underscore appended by 
either gfortran or g77.

To build numarray 1.3.3 and Numeric 23.8 against gfortran, it is 
sufficient to change 'g2c' to 'gfortran' in the list of libraries 
numarray links against (in cfg_packages.py for numarray, and in setup.py 
in Numeric 23.8).  libg2c does not need to be linked against;  in fact 
it won't get found by the numarray build procedure unless you force use 
of gcc 3.2 by using the gcc32 command.

Having done this, the problems with hangups (routines running forever) 
that Ravi reported seem not to occur.  What I do see, though, is that 
scipy.test(level=1,verbosity=10) issues a "STOP 778" for the test 
scipy.special.basic.test_basic.test_airye, causing python/ipython to 
exit at that point.   This STOP is originating in Lib/special/d1mach.f, 
which is being miscompiled by gfortran, as one can see by comparing the 
values of d1mach(3), d1mach(4), and d1mach(5) when compiled with g77 and 
with gfortran.  This is a known gfortran bug which originates in the 
fact that gfortran does not SAVE EQUIVALENCE variables properly (see 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518).  I've reported a 
copy of the same bug to bugzilla.redhat.com as bug 168252.
Despite the above, I think Ravi's patch should be incorporated into 
Scipy.  I also think that the changes he made to the routines in linalg 
should be communicated upstream to the developers of those routines, as 
the things he fixed (GOTO's which jump into the middle of IF/ENDIF 
blocks) are clearly bugs. 

Steve Walton