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

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Jakub Jelinek wrote:
> 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.

Yes, definitely.  The two possible alternatives are:
1. all function entries have the same return type
2. all function entries have one of the return types from the list I quoted
(Alternate returns don't complicate this, because they may only appear in
subroutines.)

A union is only required in the second alternative.

>>"[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.

Excactly.  Note that only scalar results are allowed in this case, so the
union which accommodates for all the possibilities with different return types
would be

union { int iresult; float fresult; double dresult;
        complex cresult; int logical; };

> 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.

Yes, but don't waste your time on squeezing optimal performance out of weird
Fortran features :-)

- Tobi