[Bug fortran/13082] Function entries and entries with alternate returns not implemented
-- Bug 13082 depends on bug 17423, which changed state. Bug 17423 Summary: gfortran segfault when compiling FM509.f from NIST testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30 17:53 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29 15:32 --- Subject: Bug 13082 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-29 15:31:39 Modified files: gcc/fortran: ChangeLog gcc/testsuite : ChangeLog gcc/fortran: trans-expr.c resolve.c trans-types.c gfortran.h decl.c trans-decl.c trans-array.c Added files: gcc/testsuite/gfortran.dg: entry_4.f90 gcc/testsuite/gfortran.fortran-torture/execute: entry_5.f90 entry_2.f90 entry_3.f90 entry_7.f90 entry_6.f90 entry_4.f90 entry_1.f90 entry_8.f90 Log message: 2005-04-29 Jakub Jelinek [EMAIL PROTECTED] PR fortran/13082 PR fortran/18824 * trans-expr.c (gfc_conv_variable): Handle return values in functions with alternate entry points. * resolve.c (resolve_entries): Remove unnecessary string termination after snprintf. Set result of entry master. If all entries have the same type, set entry master's type to that common type, otherwise set mixed_entry_master attribute. * trans-types.c (gfc_get_mixed_entry_union): New function. (gfc_get_function_type): Use it for mixed_entry_master functions. * gfortran.h (symbol_attribute): Add mixed_entry_master bit. * decl.c (gfc_match_entry): Set entry-result properly for function ENTRY. * trans-decl.c (gfc_get_symbol_decl): For entry_master, skip over __entry argument. (build_entry_thunks): Handle return values in entry thunks. Clear BT_CHARACTER's ts.cl-backend_decl, so that it is not shared between multiple contexts. (gfc_get_fake_result_decl): Use DECL_ARGUMENTS from current_function_decl instead of sym-backend_decl. Skip over entry master's entry id argument. For mixed_entry_master entries or their results, return a COMPONENT_REF of the fake result. (gfc_trans_deferred_vars): Don't warn about missing return value if at least one entry point uses RESULT. (gfc_generate_function_code): For entry master returning CHARACTER, copy ts.cl-backend_decl to all entry result syms. * trans-array.c (gfc_trans_dummy_array_bias): Don't consider return values optional just because they are in entry master. * gfortran.dg/entry_4.f90: New test. * gfortran.fortran-torture/execute/entry_1.f90: New test. * gfortran.fortran-torture/execute/entry_2.f90: New test. * gfortran.fortran-torture/execute/entry_3.f90: New test. * gfortran.fortran-torture/execute/entry_4.f90: New test. * gfortran.fortran-torture/execute/entry_5.f90: New test. * gfortran.fortran-torture/execute/entry_6.f90: New test. * gfortran.fortran-torture/execute/entry_7.f90: New test. 2005-04-29 Tobias Schluter [EMAIL PROTECTED] * gfortran.fortran-torture/execute/entry_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.412r2=1.413 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5415r2=1.5416 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.41r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gccr1=1.41r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gccr1=1.40r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gccr1=1.67r2=1.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gccr1=1.34r2=1.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gccr1=1.56r2=1.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.42r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_2.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_3.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_7.f90.diff?cvsroot=gccr1=NONEr2=1.1
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29 16:04 --- Subject: Bug 13082 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-29 16:01:17 Modified files: gcc/fortran: ChangeLog gcc/testsuite : ChangeLog gcc/fortran: trans-expr.c resolve.c trans-types.c gfortran.h decl.c trans-decl.c trans-array.c Added files: gcc/testsuite/gfortran.dg: entry_4.f90 gcc/testsuite/gfortran.fortran-torture/execute: entry_5.f90 entry_2.f90 entry_3.f90 entry_7.f90 entry_6.f90 entry_4.f90 entry_1.f90 entry_8.f90 Log message: 2005-04-29 Jakub Jelinek [EMAIL PROTECTED] PR fortran/13082 PR fortran/18824 * trans-expr.c (gfc_conv_variable): Handle return values in functions with alternate entry points. * resolve.c (resolve_entries): Remove unnecessary string termination after snprintf. Set result of entry master. If all entries have the same type, set entry master's type to that common type, otherwise set mixed_entry_master attribute. * trans-types.c (gfc_get_mixed_entry_union): New function. (gfc_get_function_type): Use it for mixed_entry_master functions. * gfortran.h (symbol_attribute): Add mixed_entry_master bit. * decl.c (gfc_match_entry): Set entry-result properly for function ENTRY. * trans-decl.c (gfc_get_symbol_decl): For entry_master, skip over __entry argument. (build_entry_thunks): Handle return values in entry thunks. Clear BT_CHARACTER's ts.cl-backend_decl, so that it is not shared between multiple contexts. (gfc_get_fake_result_decl): Use DECL_ARGUMENTS from current_function_decl instead of sym-backend_decl. Skip over entry master's entry id argument. For mixed_entry_master entries or their results, return a COMPONENT_REF of the fake result. (gfc_trans_deferred_vars): Don't warn about missing return value if at least one entry point uses RESULT. (gfc_generate_function_code): For entry master returning CHARACTER, copy ts.cl-backend_decl to all entry result syms. * trans-array.c (gfc_trans_dummy_array_bias): Don't consider return values optional just because they are in entry master. * gfortran.dg/entry_4.f90: New test. * gfortran.fortran-torture/execute/entry_1.f90: New test. * gfortran.fortran-torture/execute/entry_2.f90: New test. * gfortran.fortran-torture/execute/entry_3.f90: New test. * gfortran.fortran-torture/execute/entry_4.f90: New test. * gfortran.fortran-torture/execute/entry_5.f90: New test. * gfortran.fortran-torture/execute/entry_6.f90: New test. * gfortran.fortran-torture/execute/entry_7.f90: New test. 2005-04-29 Tobias Schluter [EMAIL PROTECTED] * gfortran.fortran-torture/execute/entry_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.43r2=1.335.2.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.149r2=1.5084.2.150 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.38.2.2r2=1.38.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.34.2.7r2=1.34.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.37.10.2r2=1.37.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.58.2.5r2=1.58.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.31.2.1r2=1.31.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.54.2.1r2=1.54.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.39.2.1r2=1.39.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From fca at mail dot cern dot ch 2005-04-08 07:14 --- Subject: Re: Function entries and entries with alternate returns not implemented Dear All, I think that the tone of the conversation is evolving in the wrong direction (I might have been partially responsible for it). Now the situation is the following: - There is a large community that needs FORTRAN (77 + 95). There is a widespread attitude that FORTRAN is dead. I do not agree, however, if it was true, the millions lines of legacy FORTRAN that people need are far from dead. - g77, after some pain and suffering, evolved to be a reasonable FORTRAN compiler. Now we suddenly (at least me) learn that it will not be maintained any more. Which means that it is dead. May be not yet, but it is clear that we cannot expect it to be around for a long time for Linux. For those using Mac's the situation is even more serious because Tiger will come out with gcc4. - We tried out the designed successor and found it very immature. In fact it is not even a proper FORTRAN compiler because it does not implement the standard. Then we started the usual interaction with the developers. And here things started to degrade. On one side we ignored how thin is this group of developers. So we were a bit demanding in our approach. On the other side the developers gave us the impression to not understand how serious the situation is for us. - The moral of the story is that the developers need some help, which I cannot provide, because I am not a compiler expert (!). However I imagine that there must be some people out there that have the knowledge and the ability to react to the save the gcc suite! cry. So I would suggest to activate our contacts and to find out if someone has the possibility to look into gFortran and provide some patches for the problems that are high priority for us. Of course this requires some good will from the developers to check and introduce these patches. - Last but not least I wonder if the g95 split is really definitive. The community would profit enormously from this split to be mended. My personal experience in this kind of business makes me rather pessimist. Let me know if it makes sense to you. Best regards, Federico On Fri, 8 Apr 2005, kargl at gcc dot gnu dot org wrote: --- Additional Comments From kargl at gcc dot gnu dot org 2005-04-08 01:21 --- (In reply to comment #25) I do not understand your tone. There is a compiler, g77, which works and implements at least the Fortran 77 standard. I don't see any reason why it should be replaced in the distribution by a compiler which is not yet mature enough to implement the same standard. Are you aware of the fact that g77 *is completely* broken with respect to the gcc-4.x branch? There is no one who is going to fix the problem because the effort to fix g77 is estimated to be equilavent to implementing an actually F95 compiler. The attitude expressed in piss off the people who owe you nothing can be very bad for the future of Linux. I don't use linux. Never have, never will. I use FreeBSD on an AMD64 platform where there are no commercially available F95 compilers. I have zero compiler writing experience, yet you'll find that I've contributed 69 patches to make gfortran work. Those patches came about because I need a compiler, and I decided to contribute something to GCC other than whining and making disparaging remarks. I don't know about my fellow contributors, but I find that I have little motivation to continue to work on gfortran occur when indivudals come here to tell us that gfortran is useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-08 07:36 --- Subject: Re: Function entries and entries with alternate returns not implemented You wrote (in bugzilla): - We tried out the designed successor and found it very immature. In fact it is not even a proper FORTRAN compiler because it does not implement the standard. Then we started the usual interaction with the developers. And here things started to degrade. On one side we ignored how thin is this group of developers. So we were a bit demanding in our approach. On the other side the developers gave us the impression to not understand how serious the situation is for us. We expect that g77 will be provided by distributors for some time to come. - The moral of the story is that the developers need some help, which I cannot provide, because I am not a compiler expert (!). Neither am I. I am a chemical engineer with a working knowledge of C, Unix and Fortran. Still, I have some patches in the tree, but only in the libgfortran library (which is simple enough so I can understand most of it :), not in the compiler proper. Of course this requires some good will from the developers to check and introduce these patches. I have just recently (yesterday :-) become an official gcc developer, and I have found the people who were here before me quite helpful. For people who want to contribute, the door is open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-08 17:10 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00855.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From twilson at ems dot jsc dot nasa dot gov 2005-04-07 20:14 --- I agree with both Federico Carminati and Alfredo Ferrari at CERN. The compiler is not usable and the impact is serious for thousands of existing fortran programs. Please fix it soon. -- What|Removed |Added CC||twilson at ems dot jsc dot ||nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-07 22:07 --- (In reply to comment #23) I agree with both Federico Carminati and Alfredo Ferrari at CERN. The compiler is not usable and the impact is serious for thousands of existing fortran programs. Please fix it soon. Sigh. Yes, it would be wonderful if a fix magically appears out of thin air. Given that there are more bugs than people actually contributing patches, you have a few choice: (1) Pay someone to fix the problem; (2) Get the source code, fix the problem, and contribute the code back to GCC; (3) wait patiently until such time that one of the few people working on gfortran has time to fix the problem; (4) or complain and piss off the people who owe you nothing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From fasso at slac dot stanford dot edu 2005-04-07 23:16 --- Sigh. Yes, it would be wonderful if a fix magically appears out of thin air. Given that there are more bugs than people actually contributing patches, you have a few choice: (1) Pay someone to fix the problem; (2) Get the source code, fix the problem, and contribute the code back to GCC; (3) wait patiently until such time that one of the few people working on gfortran has time to fix the problem; (4) or complain and piss off the people who owe you nothing. I do not understand your tone. There is a compiler, g77, which works and implements at least the Fortran 77 standard. I don't see any reason why it should be replaced in the distribution by a compiler which is not yet mature enough to implement the same standard. Your effort is appreciated, but wait to have something which works before removing the old compiler. A compiler which does not implement ENTRY is useless for most of the programs used in physics and engineering. Having that as the default Linux compiler will seriously affect my work and that of many colleagues. The attitude expressed in piss off the people who owe you nothing can be very bad for the future of Linux. I hope this is not the way user's feedback is generally received. Alberto Fasso`, Stanford Linear Accelerator Center -- What|Removed |Added CC||fasso at slac dot stanford ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07 23:27 --- (In reply to comment #25) I do not understand your tone. There is a compiler, g77, which works and implements at least the Fortran 77 standard. I don't see any reason why it should be replaced in the distribution by a compiler which is not yet mature enough to implement the same standard. Your effort is appreciated, but wait to have something which works before removing the old compiler. A compiler which does not implement ENTRY is useless for most of the programs used in physics and engineering. Having that as the default Linux compiler will seriously affect my work and that of many colleagues. What he means is asking once is fine yes but asking more and more is just bad form since we know this bug exists and yes we do know already. Also it is distros discussion what gets included, we (GCC) already said gfortran is more of a beta compiler and not really for full time use. And more of a technical preview. Now if you buy support from say RedHat or SuSE, well get them to fix it as you buy support from them. Most of us working right now on gfortran are just volunteers and yes I volunteer to work on GCC too and go through most of the bug reports and I fix the bugs which I can fix which effects the target I like the most (powerpc- darwin). I also do more work with the bug reports than what people see (well actually one person sees only I touch one bug since they usually open one bug) but I have touched and memorized almost all of the bug reports. sorry for the rant but people need to understand that we are all volunteers unless someone is getting paid to work, which I know only 2 gfortran developers are getting paid (part time or full time) to work on either GCC or gfrotran. I recall that those 2 gfortran developers are really getting paid to work on other parts of GCC and not gfortran mainly so they work on gfortran on their own time and don't get paid for it. I don't get paid for development work that I do. Again if you have a trouble with a certin distro, bring it up with them and not us since all we can do is say we know (marking the bug as a dup). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-08 01:21 --- (In reply to comment #25) I do not understand your tone. There is a compiler, g77, which works and implements at least the Fortran 77 standard. I don't see any reason why it should be replaced in the distribution by a compiler which is not yet mature enough to implement the same standard. Are you aware of the fact that g77 *is completely* broken with respect to the gcc-4.x branch? There is no one who is going to fix the problem because the effort to fix g77 is estimated to be equilavent to implementing an actually F95 compiler. The attitude expressed in piss off the people who owe you nothing can be very bad for the future of Linux. I don't use linux. Never have, never will. I use FreeBSD on an AMD64 platform where there are no commercially available F95 compilers. I have zero compiler writing experience, yet you'll find that I've contributed 69 patches to make gfortran work. Those patches came about because I need a compiler, and I decided to contribute something to GCC other than whining and making disparaging remarks. I don't know about my fellow contributors, but I find that I have little motivation to continue to work on gfortran occur when indivudals come here to tell us that gfortran is useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From alfredo dot ferrari at cern dot ch 2005-03-29 12:34 --- Hi, any news on this bug? I really appreciate the effort to build a free fortran95 compiler: the need for this is really strongly felt in our community. However, without working ENTRY's, gfortran is going to be of little use for the vast majority of the fortran particle physics and mathematics code we are using here at CERN and probably around the world. As ugly as it is (and I can assure that often it was the nicest way rather than the ugliest one of doing things) ENTRY is part of the standard and most fortran codes (at least in particle physics) make often use of it in endless places. This is true both for legacy codes where putting hands would be highly problematic, and for codes still in active development. I am afraid I can be of little help in providing patches/improvements since I am a physicist with no experience in compiler writing and/or assembler. However I have a long experience in finding bugs, reporting them and helping in assessing possible solutions, dating back to the old time of VMS machines. Please don't let us down, we fought a lot to have Linux as primary platform for physics calculations, and we want to be able to demonstrate that is was and it will be a viable and stable solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From federico dot carminati at cern dot ch 2005-03-21 21:42 --- Hello, any news on this one? The compiler is really unusable unless this problem is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-19 02:33 --- *** Bug 20069 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dmitri at unm dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
-- What|Removed |Added OtherBugsDependingO||19292 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-05 21:26 --- Updated summary, also removed the wrong-code keyword. -- What|Removed |Added Keywords|wrong-code | Summary|Function entries not|Function entries and entries |implemented |with alternate returns not ||implemented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-05 21:27 --- *** Bug 18824 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
