[patch, fortran] fixes for the EXIT intrinsic function (PR30933)

[Steve Kargl]

On Sat, Feb 24, 2007 at 08:31:11PM +0100, Tobias Burnus wrote:
> Steve Kargl wrote:
> > I think it depends on the INTENT of the arguments.  If the args are
> > INTENT(IN), then (iv) is probably best.
>
> Well, equally well one could choose only to implement the option (iii),
> i.e. only implementing kind = sizeof(int); actually, for those cases
> where we use POSIX functions (e.g. exit() etc.), I would prefer to
> directly use the kind provided by the system C library. That way one can
> give also a compile-time warning, if one down converts the precision.

Well, we already do (iv) for some intrinsics (see gfc_resolve_flush).
In fact, gfc_resolve_exit is right above gfc_resolve_flush.  You
can see that adopting FLUSH's code for EXIT fixes one of Daniel's
pr.

> Actually, for trivial intrinsics such as exit() one could even consider
> to directly generate the call to the C library instead of calling
> libgfortran which then just calls "exit()". (Ok, if the library does
> more, it makes sense to keep the calls there.)

Agreed.

> > A user calling FUNC(1_1)
> > will see that FUNC works, but under the hood _gfortran_func_i4 or
> > _gfortran_func_i8 is called depending on -fdefault-integer-8. 
> > For INTENT(INOUT) or INTENT(OUT) args, we'll probably need to go
> > with (i).
> Why? For system_cllock there are 4*4*(4+4) = 128 possibilities, if one
> wants to comply to the Fortran 2003 standard. I think in such cases it
> makes more sense to convert the arguments and convert them back.
> Currently, this is only possibly by creating the calls directly in
> trans-intrinsic.c.

Well, F95 restricts system_clock to default integer kind, so
there is 1 possibility.  With -fdefault-integer-8, gfortran has
2 implementations.  gfc_check_system_clock enforces the restriction
that the kinds match.


> >> If a subroutine/function takes multiple integer arguments, how many calls 
> >> should be considered valid?
> >>
> >>  a) all possible combinations (i1/i1, i1/i2, i1/i4, ..., i8/i4, i8/i8)
> >>  b) only those with matching types (i1/i1, i2/i2, i4/i4, i8/i8)
> >>     
> >
> > I prefer (b).  For many F95 intrinsics, this is the specified behavior,
> > and so we'll be consistent with the standard.
> 
> Well, the Fortran standard specifies often that the arguments should
> have the same type, but it (usually?) does not talk about the same kind.

This is incorrect.  Numerous intrinsics in F95 require not only 
matching type but also type parameters.  See F95 section 13.  The
first examples I looked at ASSOCIATED and ATAN2 support my claim.

> In Fortran 95 several intrinsics accepted only the default integer,
> however, in Fortran 2003 most intrinsics accept now any kind. Thus for
> most standard intrinsics, (a) is required.

Gfortran is targeting Fortran 95.  Yes, we've added numerous F2003
features, but fundamentally gfortran is F95.  (a) is only required
for the F2003 standard intrinsics.  gfortran is free to do whatever
we want with its non-standard intrinsics.

> Maybe one should extend the gfc_tree to support the back-conversion of
> the arguments after the function call. Otherwise we will end up with
> either dozens of functions in the library (up to 128 per intrinsic!) or
> we have to implement everything in trans-intrinsics.c.

You're probably correct that F2003 is going to make us rethink 
the library implementation of standard intrinsics.  However, for
the non-standard intrinsics we can choose (and document) the
behavior.  The user is expected to read the docs.

> signal() is actually an example where we currently don't do the back
> conversion (PR  29651).

I don't remember the details with signal(), but ISTR that it has
some quirky behavior.

-- 
Steve