kargl[208] ../../../bin/gfortran -x f95 -static p.f Assertion failed: (sym->backend_decl), function gfc_get_symbol_decl, file ../../gcc/gcc/fortran/trans-decl.c, line 665. p.f: In function `x': p.f:2: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Environment: System: FreeBSD 12-230-81-20.client.attbi.com 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Sat Nov 15 22:11:52 PST 2003 kargl@12-230-81-20.client.attbi.com:/usr/local/obj/usr/src/sys/HOTRATS i386 host: i386-unknown-freebsd5.1 build: i386-unknown-freebsd5.1 target: i386-unknown-freebsd5.1 configured with: ../gcc/configure --prefix=/usr/home/kargl/gcc-ssa/work --disable-libmudflap --enable-languages=c,f95 --with-gmp=/usr/local How-To-Repeat: * =foo7.f in Burley's g77 test suite. subroutine x real a(n) common /bar/n continue entry y(a) call foo(a(1)) end
Confirmed on the tree-ssa (20031115).
Here's an even shorter testcase: ============================================= subroutine foo entry bar(i) i=0 end ============================================= The problem seems to be in the frontend, so I removed the host/build/target triples.
*** Bug 13254 has been marked as a duplicate of this bug. ***
*** Bug 13570 has been marked as a duplicate of this bug. ***
An ICE is never an enhancement, it's always a bug.
This seems to be a result of a more fundamental problem: programs with ENTRY's compile flawlessly, but don't work. No symbol is generated for the entry: [tobi@marktplatz tests]$ cat pr13082.f90 subroutine foo entry bar end [tobi@marktplatz tests]$ gfortran pr13082.f90 -S [tobi@marktplatz tests]$ cat pr13082.s .file "pr13082.f90" .text .align 4 .globl foo_ .type foo_, @function foo_: pushl %ebp movl %esp, %ebp popl %ebp ret .size foo_, .-foo_ .ident "GCC: (GNU) 3.5-tree-ssa 20040501 (merged 20040428)" .section .note.GNU-stack,"",@progbits There is code in trans-decl.c which should catch this, but it doesn't trigger, with my testcase that function is never called: 748: if (sym->attr.entry) 749: gfc_todo_error ("alternate entry");
I changed the summary to reflect the real problem. I also added the wrong-code keyword, as these seem to be the two real-life consequences of this problem.
*** Bug 16484 has been marked as a duplicate of this bug. ***
*** Bug 16520 has been marked as a duplicate of this bug. ***
*** Bug 16945 has been marked as a duplicate of this bug. ***
Subject: Bug 13082 CVSROOT: /cvs/gcc Module name: gcc Changes by: pbrook@gcc.gnu.org 2004-08-17 15:34:12 Modified files: gcc/fortran : ChangeLog decl.c dump-parse-tree.c gfortran.h module.c parse.c resolve.c st.c symbol.c trans-array.c trans-decl.c trans-stmt.c trans-stmt.h trans-types.c trans.c trans.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: entry_1.f90 Log message: 2004-08-17 Paul Brook <paul@codesourcery.com> Tobias Schlueter <tobias.schlueter@physik.uni-muenchen.de> PR fortran/13082 * decl.c (get_proc_name): Update mystery comment. (gfc_match_entry): Check for errors earlier. Add entry point to list. * dump-parse-tree.c (gfc_show_code_node): Print EXEC_ENTRY nodes. * gfortran.h (symbol_attribute): Add entry_master. Document entry. (struct gfc_entry_list): Define. (gfc_get_entry_list): Define. (struct gfc_namespace): Add refs and entries. (enum gfc_exec_op): Add EXEC_ENTRY. (struct gfc_code): Add ext.entry. * module.c (ab_attribute, attr_bits): Remove AB_ENTRY. (mio_symbol_attribute): Don't save/reture addr->entry. (mio_namespace_ref): Refcount namespaces. * parse.c (accept_statement): Handle ST_ENTRY. (gfc_fixup_sibling_symbols): Mark symbol as referenced. (parse_contained): Fixup sibling references to entry points after parsing the procedure body. * resolve.c (resolve_contained_fntype): New function. (merge_argument_lists, resolve_entries): New functions. (resolve_contained_functions): Use them. (resolve_code): Handle EXEC_ENTRY. (gfc_resolve): Call resolve_entries. * st.c (gfc_free_statement): Handle EXEC_ENTRY. * symbol.c (gfc_get_namespace): Refcount namespaces. (gfc_free_namespace): Ditto. * trans-array.c (gfc_trans_dummy_array_bias): Treat all args as optional when multiple entry points are present. * trans-decl.c (gfc_get_symbol_decl): Remove incorrect check. (gfc_get_extern_function_decl): Add assertion. Fix coment. (create_function_arglist, trans_function_start, build_entry_thunks): New functions. (gfc_build_function_decl): Rename ... (build_function_decl): ... to this. (gfc_create_function_decl): New function. (gfc_generate_contained_functions): Use it. (gfc_trans_entry_master_switch): New function. (gfc_generate_function_code): Use new functions. * trans-stmt.c (gfc_trans_entry): New function. * trans-stmt.h (gfc_trans_entry): Add prototype. * trans-types.c (gfc_get_function_type): Add entry point argument. * trans.c (gfc_trans_code): Handle EXEC_ENTRY. (gfc_generate_module_code): Call gfc_create_function_decl. * trans.h (gfc_build_function_decl): Remove. (gfc_create_function_decl): Add prototype. testsuite/ * gfortran.dg/entry_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.151&r2=1.152 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&r1=1.18&r2=1.19 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/dump-parse-tree.c.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.22&r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcc&r1=1.13&r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/parse.c.diff?cvsroot=gcc&r1=1.16&r2=1.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/st.c.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.16&r2=1.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.31&r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.h.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.c.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4147&r2=1.4148 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Can we close this as fixed or are there still issues that need to be tackled?
Subject: Re: ENTRY statement not implemented Close it! Thanks, Paul ----- Original Message ----- From: "reichelt at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: <paulthomas2@wanadoo.fr> Sent: Wednesday, August 18, 2004 12:53 PM Subject: [Bug fortran/13082] ENTRY statement not implemented > > ------- Additional Comments From reichelt at gcc dot gnu dot org 2004-08-18 10:52 ------- > Can we close this as fixed or are there still issues that need to be tackled? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
! Functions still do not work. function foo() integer foo integer bar entry bar () bar = 42 end function
Subject: Re: ENTRY statement not implemented Oh shoot! Thanks Paul ----- Original Message ----- From: "pbrook at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: <paulthomas2@wanadoo.fr> Sent: Wednesday, August 18, 2004 1:05 PM Subject: [Bug fortran/13082] ENTRY statement not implemented > > ------- Additional Comments From pbrook at gcc dot gnu dot org 2004-08-18 11:05 ------- > ! Functions still do not work. > function foo() > integer foo > integer bar > entry bar () > bar = 42 > end function > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
Updated summary to reflect current status.
Alternate returns are implemented via functions, so entries don't work for these either.
Updated summary, also removed the wrong-code keyword.
*** Bug 18824 has been marked as a duplicate of this bug. ***
*** Bug 20069 has been marked as a duplicate of this bug. ***
Hello, any news on this one? The compiler is really unusable unless this problem is fixed.
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.
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.
(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.
> 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
(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).
(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.
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. > > > > > >
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.
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00855.html>
Subject: Bug 13082 CVSROOT: /cvs/gcc Module name: gcc Changes by: jakub@gcc.gnu.org 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 <jakub@redhat.com> 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 Schl"uter <tobias.schlueter@physik.uni-muenchen.de> * gfortran.fortran-torture/execute/entry_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.412&r2=1.413 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5415&r2=1.5416 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.41&r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.41&r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&r1=1.40&r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.67&r2=1.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&r1=1.34&r2=1.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.56&r2=1.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.42&r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_7.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_8.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Bug 13082 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: jakub@gcc.gnu.org 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 <jakub@redhat.com> 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 Schl"uter <tobias.schlueter@physik.uni-muenchen.de> * gfortran.fortran-torture/execute/entry_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.43&r2=1.335.2.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.149&r2=1.5084.2.150 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.38.2.2&r2=1.38.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.7&r2=1.34.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.37.10.2&r2=1.37.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.5&r2=1.58.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.2.1&r2=1.31.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.2.1&r2=1.54.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.2.1&r2=1.39.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_3.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_7.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_6.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_8.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
Fixed.