Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153715 - Horribly bad: fortran useless as it is in gcc4
Summary: Horribly bad: fortran useless as it is in gcc4
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc4
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-05 07:39 UTC by Alfredo Ferrari
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-09 08:59:11 UTC

Attachments (Terms of Use)

Description Alfredo Ferrari 2005-04-05 07:39:16 UTC
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 (
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):

How reproducible:

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

Additional info:

Comment 1 Jakub Jelinek 2005-04-05 10:30:40 UTC
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.

Comment 2 Alfredo Ferrari 2005-04-05 12:05:54 UTC
Hi Jakub

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.  

Comment 3 Alfredo Ferrari 2005-04-05 19:31:41 UTC
... 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

Comment 4 federico.carminati 2005-04-05 23:22:10 UTC
   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, 
Federico Carminati

Comment 5 paola.sala 2005-04-06 15:57:31 UTC
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.
Best Regards
Paola Sala ( italian national institute of  nuclear physics ,INFN)   

Comment 6 Lawrence S. Pinsky 2005-04-06 22:32:03 UTC
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)

Comment 7 Alfredo Ferrari 2005-04-07 07:35:41 UTC
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
was dated
 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
   development pace)?
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.

Comment 8 Thomas Wilson 2005-04-07 20:30:37 UTC
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).

Comment 9 Jakub Jelinek 2005-04-09 08:59:11 UTC
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
the results.

Comment 10 André Fettouhi 2005-06-19 10:37:45 UTC
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.

Kind Regards

André Fettouhi

Comment 11 Jakub Jelinek 2005-06-19 18:26:29 UTC
gfortran support library is not called libg2c.*, but libgfortran.*.
So when using gfortran, you need to use -lgfortran in places where you used
-lg2c before.

Note You need to log in before you can comment on or make changes to this bug.