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: linking files compiled with older gfortran


Dear Raju,

thanks for your comments.


kamaraju kusumanchi wrote:
> Every time some problem or the other comes up and the standard answer
> is that upgrade to the latest version. In a corporate/academic
> environment, on
> a multi user production system, upgrading compilers, libraries is a
> painful process (to say the least).

I full hearty agree. However, I do not see any solution. We cannot
travel into the past to fix problems there, we cannot maintain more than
the current three versions (last release 4.4.x, previous release 4.3.x,
developer version 4.5). Regarding the released versions: One could argue
that more fixes should go to the released version, but their the goal is
to make sure that there is no regression at all; consequently only
non-invasive regressions fixes and serious bug fixes go into the
branches. (Besides, I cannot imaging that many departments are
re-compiling GCC to get newer bug fixes.)

The only big issue is the library compatibility. I think gfortran has so
far always bumped the library version, which means that old programs
continue to work. Thus "only" the problem of linking old libraries
remains. The goal for 4.3 was to keep the ABI stable and be always
backward compatible; also versioned symbols were introducted to help to
make this possible (which was one of the reasons GCC 4.2 and GCC 4.3 had
incompatible libraries). Since then (4.3, 4.4, 4.5 so far) the ABI
remained stable - which was not trivial as GCC 4.4 had several new I/O
features which had to be implemented such that 4.3-compiled code still
works with the 4.4 library. Thus the ABI compatibility is seen as
important but the ABI is not sacrosant.

By the way, I do not see any difference to commercial vendors: There,
library incompatibilities are also relatively common.


> Anyway, I am mainly interested in seeing a standard confirming fortran
> 90 (or 95) compiler with full debugging support, good optimization
> capabilities. Currently I see very good fortran 90/95 support, decent
> optimization. I'd like to see more debugging support. Gfortran's
> development has always been "to try and catch up with the
> latest standard". With Fortran standard being updated constantly this
> is always going to be a lagging process.

I think GNU Fortran has a rather good debugging support, although some
parts (like for ENTRY) are still missing, but several apparent issues
are actually missing features in the debugger. You should try gdb with
the Red Hat patches (-> Fedora 11, openSUSE Factory/pre-11.2 or in
archer.git), which adds support for Fortran90 arrays and has a better
module support. Are you missing something specific in terms of
debugging/diagnostics?


One is always lagging behind a standard - as one cannot implement
something according to a standard before it has been standardized.
Otherwise, I also believe that most users only need a Fortran 90/95 or
maybe only a FORTRAN 77 compiler, still, the number of people wanting to
use certain Fortran 2003 features is not that small (C binding, command
line arguments, ...). In terms of development, the focus is also not
only on new Fortran 2003/2008 features; for instance the compile-time
and run-time diagnostics have been largely improved in 4.5 - and the I/O
has been modified to be faster. I think you always see work on all of
the following items: Bug fixes, compile-/run-time diagnostics,
performance, features for newer Fortran/OpenMP/... standards, cleanup.

It depends on the taste and personal needs/interests whether a certain
Fortran 2003 feature, a bug fix for a very special case of Fortran 90+,
a certain run-time/compile-time diagnostic, or a specific performance
improvement is more important. The development is driven by personal
interest of the one developing a patch, but also by input from the users
(via this mailing list, via bug reports, via comp.lang.fortran).


> As gfortran developers, many on this list might be more interested in
> catching up with the latest standard. But as a user, I am more
> interested to see a compiler which implements a specific standard
> completely before stepping into the next standard.

First, I want to remark that almost all gfortran developers come from
academia and use gfortran to compile their real-world Fortran programs;
some of these might use certain Fortran 2003 features, but many do not.
And thus performance and diagnostics are also regarded as important.

A certain feature completeness for Fortran 95 was seen as extremely
important for 4.2 and 4.3 and thus the development concentrated on this.
However, I think with 4.3 the point was reached were one could claim
that Fortran 95 is fully implemented (except of bugs). Bugs are
unfortunately unavoidable - and often fixed relatively quickly. But from
the bug reports and c.l.f posts I have the impression that gfortran does
fairly well. As Fortran 95 is essentially implemented and bugfree, there
is time to work also on other items such as diagnostics, performance but
also on Fortran 200x features.


> May be the solution is to branch out gfortran into g95, g03 etc.
> whenever a new standard is made. For example, g95 concentrates on
> fortran 95 code, its optimization, debugging support etc., but does
> not much care about F2003 features. g03 concentrates on fortran 2003
> standard code etc.,

I think that is extremely impractically; working on several code
branches is a mess. I have a good example why working on a single code
is useful and why e.g. restricting to Fortran 90 will not help with the
ABI: The proposed array descriptor update is not only for Fortran 2008
(coarrays, array rank > 7) or Fortran 2003 (polymorphic types), but it
is (also) for Fortran 95. There are certain F95 bugs which are unfixable
without such a change (cf. F90 bugs 35719, 35718, 38471).

Thus the goal for this array-descriptor update is to fulfil all the
needs for F95/F2003/F2008 and the upcoming technical report to increase
the chance that the ABI will be again stable for a while.

Another example for work which helps in multiple ways is the new
-fwhole-file option: It improve diagnostics and performance at the same
time.

 * * *

In conclusion, I do not see how the general development scheme can be
improved. However, I think smaller things  can be improved - and
explicit suggestions are highly welcome. Comments of the kind "PR...
really should be fixed soon", "debugging issue such and such is
important", "... still does not work", etc. definitely influences the
development priorities.

Tobias

PS: While writing this email I came to the conclusion that the library
version should be bumped and the ABI broken when changing the array
descriptor. Otherwise one might see strange bugs when array descriptors
are passed between a 4.4-compiled library and a 4.[56]-compiled program.
In that sense, doing a lot of effort to keep the ABI is partially
contraproductive. (For Fortran 77 libraries, which have no array
descriptors, ABI compatibility is be more useful.)


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