This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Matthias Klose wrote: 
Some months ago, the GCC/gfortran developers asked distributors to still
ship g77 in their next release of a distribution.  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.

IMHO as of gcc 4.2, or perhaps even 4.1, gfortran is stable enough to be generally usable as the system Fortran compiler. Of course, if you want 100% bug-for-bug compatibility with g77, then g77 is your only option.

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.

Whether this is a bug in gfortran, (mis)use of aggressive optimization (e.g. -ffast-math), a bug in the test harness or whatever is hard to say without more information.

Questions that did come up on this check:

- 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.

Yes, as Steve Kargl said, gfortran will almost certainly never support all the compiler options g77 supports. It's a different compiler.

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

To be pedantic, gfortran doesn't have a "f77 mode". Anyways, inability to produce a correctly working binary from standard-conforming F77 would be a bug. gfortran also supports a number of extensions, while not the same set of extensions as g77 there is still a lot of overlap. But there might be a number of explanations for the test failures that don't prove to be bugs.

- 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.

This is going to be a problem. But as debian has made a number of successful ABI transitions (at least two for C++, and the libc5->glibc one?), I'm sure you can figure it out.

The basic problem is that by default g77 uses the f2c ABI, thus inheriting some weirdness, while gfortran uses basically the same as C99. See the -f2c option in the manpage and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178

Of course, you can choose to always use -f2c with gfortran, but then you'll be incompatible with everyone else. As well as possibly take a small performance hit, issues with excess precision etc.

In addition to ABI issues, there might also be problems e.g. with library code doing I/O, if the library depends on main() initializing it before handing over to the user code (at least gfortran does this, don't know about g77).

Personally I believe the best solution is not to mix gfortran and g77. Although I have broken this rule myself by using e.g. the ubuntu packages for atlas, lapack and netcdf together with gfortran and if one is really careful it might work (mostly).

And just to make your life even more miserable, there will be ABI breakage in libgfortran in the not too far future. IIRC 4.2 bumped the so version from 4.1, and it will probably happen again for 4.3. Hopefully we'll get symbol versioning for 4.3 and thus get some semblance of ABI stability, courtesy of yours truly, but the patch has stalled due to some minor problems and I'm quite busy with Real Life(TM) at the moment so I haven't had time to look into it. :(

- 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?

Gfortran pretty much follows the C ABI. I don't know about g77, except for the f2c weirdness I'd guess it also follows C.

I'm aware that the fortran ML may not be the ideal forum to discuss
this; maybe we can move these conversations to distribution specific
lists after some time.

Well distributions are big "customers" as you put gfortran into the hands of many users, so I think it's nice that you take an interest in gfortran.

Another thing you might want to consider is that now that you're providing a Fortran 95 compiler, presumably other developers will want to add F95 libraries that provide module files (say, the F90 interface to netcdf, lapack95 etc.). Coming up with a policy for these .mod files (where should they go?) might be easier now than a few years later when you have a few dozen libraries doing it their own way. IIRC the default is to put them into the normal include directories, but since they are somewhat system(?) and compiler version dependent you might want to put them somewhere else. Or then not, it's up to you of course.


--
Janne Blomqvist

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]