Red Hat Bugzilla – Bug 153715
Horribly bad: fortran useless as it is in gcc4
Last modified: 2007-11-30 17:11:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1
Description of problem:
gfortran as in gcc4 doesn't handle ENTRY statements which are part of the fortran standard. The bugs is known to the gfortran maintainers (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082).
This is not a "small" issue: here at CERN almost no existing fortran code can be compiled because of this. I counted some 2500 ENTRY statement in the CERN Library base code only and I can go on. I already wrote to the gcc maintainers as well as other colleagues did but I am afraid they do not fully realize the seriousness of the issue. It is nice to have eventually a fortran90/95 capable compiler, howeverif this has to break MOST existing fortran(77) code it would be a nightmare.
Having a critical (it is not obvious at all to replace an ENTRY, usually it implies rewriting completely the affected routine) part of the standard unsupported should be top priority to fix.
As far as of today gfortran SHOULD NOT be pushed as the standard compiler for fc4, since it is pretty unusable.
Please don't tell me there are back-compatibility compilers included in fc4t1,
a) this is just short term damage control
b) how about mixed enviroment (c/fortran/c++) plus some core libraries
(ie qt just to give an example from real life)?
A fortran compiler like this will ingenerate a disaster when it will hit production enviroments: think about all legacy engineering codes which will likely not compile at all. I don't think it is a good policy for GNU/Linux to break one of the major langauges and possibly the one with the largest legacy base.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.try to compile a fortran code with an ENTRY statement
3.... collect the pieces
Actual Results: No way to compile successfully ENTRY with gfortran
Expected Results: It should have compiled and worked
For the time being, compat-gcc-g77 is really the answer for you.
You should be able to mix gcc/g++ compiled objects with compat-gcc-g77 compiled
ones just fine.
gfortran does not pretend to be a 100% replacement for g77 and that's why
compat-gcc-g77 is provided as well (otherwise it wouldn't be included).
As the missing feature is tracked upstream, I don't think it makes it any sense
to track it here as well. If/when upstream adds support for it, we can consider
backporting it e.g. from 4.1 to 4.0, so you can reopen once that happens.
I understand that compat-gcc-g77 is a temporary (bad) solution.
However I don't believe it will stay forever and it implies using different
compilers for different routines, not only c/c++ vs fortran, but even f77 vs
f90!! It's a total mess. Further your "if/when" is very significant about the
lack of recognition how big a problem this is.
These are exactly the situations which leave you defenseless when you try to
explain the choice to move to linux with your bosses. One of the oldest and most
stable standards for coding is suddenly broken and perhaps "if/when' it will be
fixed. Let me know when there will be such incomplete fortran in an Enterprise
edition how the customers will react... Meanwhile very little debugging will go
into gfortran since most codes simply don't run on it ==> "if/when" the ENTRY's
will be fixed a pletora of problems could appear.
... furthermore, compat-gcc-g77 inside fc4t1 seems to be from a VERY OLD
version, gcc-3.2.3, while the one running ie in fc3 is based on gcc-3.4.2.
I have a few issues with this that I would like to see clarified to understand
if using compat-gcc-g77 as provided is really an option or not:
a) bug fixing: there were various bugs here and there which got fixed, is this
version up-to-date with the lates bug fixing for g77 and gcc3 ? If not it is useless
b) In a world where 64 bit machines are now present there is a need to be able
to compile with -m32 or -m64 depending on situations. Are these flags supported
on such an old version? If not it would be insane, building and running on
a mixed environment needs them
c) Some optimization flags for specific processor type (ie Centrino but not
only) appeared only on the latest gcc-3's, have they been backported to these
"compat" packages, or are we suppossed to go back and lose important pieces of
And besides a) b) and c) why the compatibility packages are not provided for the
latest gcc-3.x (gcc-3.4 I believe)?
Thanks a lot for your attention
I am the computing coordinator of the ALICE experiment at CERN (1000+ collaborators worldwide,
almost all on Linux). With all due respect for the developers of gfortran, we do need a fortran compiler
on Linux, and a compiler that does not accept standard conforming code is simply not usable. We are
working on one of the largest grid in operation, counting something like 10,000 CPU's. Heterogeneity is
already a nightmare to control. The introduction of "backward compatibility" compilers will make the
situation very difficult to manage. I think this problem should be taken very seriously. Best regards,
It seems to me that this bug is not at all "closed". If I understand well,
the new standard fortran compiler in gcc4 is not intended to be a standard
compiler... then why is it distributed? Backward compatibility compilers should
be intended as emergency tools for very specific situations, the idea of having
thousands of users working on back compatibility a nonsense. Maybe the issue has
been underestimated, but fortran entry points are heavily used in codes that are
distributed and used worldwide. I think that this problem should be fixed as
soon as possible.
Paola Sala ( italian national institute of nuclear physics ,INFN)
This is a really serious problem, and the "bug" issue should not be closed.
One of the things that was becoming nice about the evolution of RH's Limnux
distribution was the trend toward stability in the compilers where new
versions were more likely to be kind to existing code and in the cases where
the new versions did break things, the fixes were getting simpler. Now, this
is a like a train wreck in the whole progression. Fortran Entry Points are an
essential feature of Fortran, and I fail to see why it would not have been
implemented in gFortran intitally anyway. The idea of having a special
backward compatible compiler that does not incorporate all of the features of
the most recent gcc compilers also strikes me as bizzare
L. Pinsky (University of Houston)
Apparently a lot of people is unhappy with the non-solution to this issue.
I share the opinion that a compatibility package (by definition of limited
life span) is not a viable solution for a major bug in a major language compiler
-> so I reopen the bug, at least to initiate a serious discussion on how to come
out of this mess (see below).
A solution like this will hardly work with thousands of users as we have, many
of them with no control of what is installed or is not on their machine. I
believe we need an "official" fortran compiler reliable and complete, and
gfortran doesn't appear to be fit, at least up to now (there are many other
worrying bugs around BTW and some of them could be devastating as well if I
didn't misinterpret what is on the gfortran TODO list). What is even more
devastating is to notice that the original bug (13082) about entries in gfortran
Opened: 2003-11-17 01:33
so it is around since 1 year and half!! This gives little confidence in the
evolution process with gfortran.
I understand this is for you an upstream bug, however some questions are
relevant for fedora:
a) why to substitute as default a working (even though limited) compiler
with a broken one (promising on paper, but apparently with no real
b) why gfortran? If supporting fortran90/95 was the issue (a very legitimate
one), then g95 could have been a better alternative.
c) Most important: how one can be confident that these issues are going to find
a quick and robust solution given the apparent stall of gfortran development
(1 1/2 year for a serious bug is nonsense)
Then a couple of hopefully "reasonable" requests
1) if (and I still hope not) we have to live for some time with a compatibility
compiler, would it be possible to have a compat-gcc-3.4.x... on top of
the one which is distributed with Fedora Core 4 test 1?
2) what about including g95 which appear to be in much better shape of gfortran
as a parallel or default solution until gfortran matures enough?
I volunteer in testing reasonably extensively g95 before any action in case
the latter proposal is felt reasonable/feasible
3) Since gfortran doesn't provide full fortran77 support, why don't keep g77
in the official gcc suite until gfortran becomes decently usable (I know this
is not a problem for you, but I saw there are a couple of RedHatters in the
gcc steering committee)?
Please take the first two proposal as possible RFE's for fc4t1, and please find
the time to answer the worries expressed at the beginning. I understand there is
a whole community puzzled by this issue.
To this litany of comments, I would like to say this problem impacts a larger
community of users which includes NASA where we also run the particle physics
code developed at CERN on RedHat Linux systems. A fundamental change like this
dominoes into thousands of Linux-based applications. Considering all of the
other problems we are faced with, please do not add this one. It is a
single-point failure in the whole architecture. Also, should this type of
problem continue it may create a credibility issue with Linux itself. For many
of us it has been an uphill struggle to convince management people to invest in
Linux. âIf/whenâ the naysayers get ahold of this one, our progress could
experience a real step backwards. Please take our comments seriously and do
something to correct the situation promptly.
Thomas Wilson (NASA, Johnson Space Center).
To answer #7.
a) FC4's primary compiler is GCC4. gfortran is an integral part of GCC4
b) same as a)
c) there is nothing that prevents you from helping with gfortran, any help
will be certainly appreciated. Even if you are not able to help on the
compiler side, you can e.g. help with providing extensive test coverage
for all the language features you are using in your programs (both
g77 and gfortran have very limited test coverage)
1) not for FC4, there are already too many compilers and the distribution
is already too large. Maybe a 3.4 based g77 could be provided in Fedora
2) if you find somebody who would be willing to package it up and maintain
as part of Fedora Extras, I think this is not going to be rejected
3) fixing g77 frontend so that it works with tree-SSA and other changes made
in 4.0 is probably more work than fixing up the remaining issues in gfortran
This kind of organized lobying is not the way things work in Fedora nor in RHEL.
In RHEL4, g77 is the primary Fortran compiler, gfortran was released there as a
technology preview only and that is going to stay that way for the lifetime of
the RHEL4 product. If you are a RHEL customer and have feature requests
regarding RHEL5 (which will surely ship gfortran and very likely some
compatibility g77 compiler in addition to that), you can escalate them through
your support contact.
That said, I went up and implemented ENTRY support for FUNCTIONs (so far only
as long as the result types are identical) and for SUBROUTINEs with alternate
So if you want to help, you can certainly test that on your code and report
I have a similar proplem on FC4 (final) I a trying to compile a Fortran program
along with some c/c++ stuff but the fortran parts fails because -lg2c is missing
but gcc-g77 is installed along with compat-f2c and all the other fortran
compilers old and new etc.
gfortran support library is not called libg2c.*, but libgfortran.*.
So when using gfortran, you need to use -lgfortran in places where you used