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, because 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: Always Steps to Reproduce: 1.try to compile a fortran code with an ENTRY statement 2.... 3.... collect the pieces Actual Results: No way to compile successfully ENTRY with gfortran (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082) Expected Results: It should have compiled and worked Additional info:
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.
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.
... 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 optimization? 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
Hello, 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
Hello, 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)
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 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.
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 Extras 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 returns: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00855.html http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00908.html So if you want to help, you can certainly test that on your code and report the results.
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
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.