Re: [patch, fortran] Add _gfortran_error_stop_numeric

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Sun, May 9, 2010 at 11:21, Daniel Franke <franke.daniel@gmail.com> wrote:
> I haven't read the standard, so I don't know if it's allowed, but: how does
> this patch handle non-default-integer kinds and -fdefault-integer-8?

The F2008 draft says that the integer stop code must be of default
kind; however, as you mention  we must still handle
-fdefault-integer-8.  That being said, IMHO that can be left for a
follow-on patch.

> In other words: would this (a) be valid, (b) be accepted and (c) would it
> print the right value - error_stop_numeric only takes a GFC_INTEGER_4?
>
> ÂERROR STOP HUGE(0_8)
>
> I expect we have the same issue here as with all the other intrinsics in the
> library ...

IMHO the only sane way to handle this is to have the frontend generate
a temporary of the correct kind, copying the real argument to the
temporary, calling the library function with the temporary, and
afterwards if the argument is not INTENT(IN), copy the value back to
the real argument variable.  We could special-case the common case
where both the real argument and the library procedure have the same
kind, or we could trust the middle-end to get rid of the unnecessary
temporary in that case.

For this particular case where we have only an argument of default
kind we could in principle do it the old way by having a
error_stop_numeric_i8 library function (albeit at the cost of causing
some unnecessary library bloat), but the real problem is with the
intrinsics. F2003, in contrast to F95, allows most integer arguments
to be of any kind, and there is no restriction that all integer
arguments must be of the same kind. So consider an intrinsic with,
say, 2 integer arguments; we have to handle all combinations of kinds
2,4,8,16 and we'd need a ridiculous number of library procedures.
Hence typecasting in the frontend is the only realistic option.

-- 
Janne Blomqvist