Re: [PATCH] Support ENTRY in FUNCTIONs (PR fortran/13082)

[Jakub Jelinek <jakub at redhat dot com>]

On Sat, Apr 09, 2005 at 10:49:16AM +0200, Tobias Schl?ter wrote:
> > Non-matching types, such as
> ...
> > can be handled by creating a union of all result types and returning it
> > by reference from entry master function, but it will require some more
> > hacking.
> 
> Note that the same union can be used for all cases because of the sentence
> beginning on the last line of p.209:

I don't have a copy of the standard, so all I gathered about ENTRY was from
googling around.  Still, if the type is the same, it is IMHO more efficient to
return it directly and not as a union.  Even if the union is not returned by
reference explicitely, but as a return value from the entry master function,
many targets will choose to return it by reference anyway.
So if we know all the types are say integer or all of them are real4, it is
better to return them that way.  On many targets this will mean either that
a tail call can be used, or at least that the return value won't be copied
around by the entry thunks.

> "[if the results are not of the same type], they are storage associated and
> shall all be scalars without the POINTER attribute and one of the types:
> default integer, default real, double precision real, default complex, or
> default logical."
> 
> This restriction is not currently checked by the frontend.

So e.g. CHARACTER is not allowed result type if the results are not all
the same type?  That would simplify things a little bit.

It perhaps would be better to have the UNION_TYPE the DECL_RESULT of
the entry master function instead of explicitely return it by reference
in the frontend.  That way the target has a choice between returning it
directly or indirectly depending on its ABI.

	Jakub