Re: changing build dependencies in a distribution from g77 to gfortran

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Fri, Jan 26, 2007 at 12:00:00PM +0100, Matthias Klose wrote:
> Some months ago, the GCC/gfortran developers asked distributors to still
> ship g77 in their next release of a distribution.

I don't recall anyone making such a request.  We do tell people,
that use RH or Debian with gfortran 4.0.x, to upgrade to a newer
version of gfortran from the gfortran wiki.  gfortran in 4.0.x
is at best alpha quality software. 

> Looking forward at
> the Debian etch release on the horizon and at upcoming Ubuntu releases,
> I had a first look at making g77 the secondary choice as a f77 compiler,
> or removing it from the release altogether and using gfortran as the
> preferred f77 compiler.

Debian etch uses gcc/gfortran 4.2.0 (if and when it's releases), then
you should be able to dump g77 entirely.

> I tried to build numpy using gfortran on i486, starting with the build
> dependencies (which are for debian/ubuntu refblas3, lapack3, atlas3).
> 
> - the refblas3 package builds, but some complex number tests fail.
>   Compiler options used in the build are not recognized by gfortran.

Details?  If refblas3 is the code available from netlib, then BLAS
builds and works fine, but it does depend on options.  For example,
DO NOT USE -ffast-math. 

> - If you want to use the gfortran driver as a g77 replacement, it should
>   understand all of g77's command line options, or maybe a gfortran
>   wrapper should be used.

This won't happen.  There are too many g77 options that are useless
with gfortran and adding code simply to ignore these option is not
very productive.  gfortran is not a g77 replacement.  g77 is a Fortran
77 available with gcc-3.4.6.  gfortran is a Fortran 95 that is 
available in gcc-4.x.  Some effort has been made for backwards 
compatibility with g77 (e.g., all of the nonstandard intrinsic 
procedures have been implemented).  But, you should consider gfortran
to be a completely different compiler with a possibly different 
set of options. 

> - Are test failures for code that works well when compiled with g77
>   be seen as regressions in gfortran's f77 mode?

It depends on several factors.  First, if the failure occurs when one
aggressively (ab)uses gcc options (e.g., -ffast-math), then it is most
likely not a regression.  Second, if the code runs with "g77 -O file.f"
but fails with "gfortran -O file.f", then this may be considered 
a regression (depending on the conformance of file.f to the Fortran
standard).  Third, if file.f is using nonstandard extensions to
the Fortran 77 language, then gfortran may have either followed the
Fortran 95 standard to compile the file.f or the nonstandard extension
doesn't work the same in gfortran.  An example of this failure mode is
the initialization of a REAL variable in a DATA statement by a 
BOZ-literal-constant.  This isn't going to do what one wants.  Fourth,
you can always send the code or a URL to the code here, and we'll
check out the failure.

> - Is code, which is party built with g77 and partly built with gfortran,
>   supposed to work?  This situation comes up when starting to build
>   some packages with gfortran, while others are still built with g77.
>   This is a real concern for distributions like debian supporting
>   partial upgrades of packages.

I've never tried to do this.  But, I believe the -ff2c gfortran option
exists to permit this.  Read the gfortran docs.

> - Does the long double change (64->128) on alpha, powerpc, sparc, s390
>   has consequences for gfortran and on C/C++ libraries interfacing
>   with g77/gfortran code?

I know nothing about g77 and the impact of these changes on interfacing.
g77 behavior in this task is sort of off-topic for this list.
gfortran maps REAL(4) to float, DOUBLE PRECISION (or REAL(8)) to double,
and REAL(10) or REAL(16) to long double.  You need to be more
specific about what your concerns are.  In fact, gfortran uses libm
for many of the intrinsic math function, so the mapping of Fortran
types to C types is natural.  I'll also point out that work is 
underway for Fortran 2003's ISO C BINDING intrinsic module, which is
designed to facilitate mix language programming. 

-- 
Steve