Bug 13082

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.