This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch, fortran] fixes for the EXIT intrinsic function (PR30933)
Steve Kargl wrote:
On Sat, Feb 24, 2007 at 08:31:11PM +0100, Tobias Burnus wrote:
Steve Kargl wrote:
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.
However, ASSOCIATED and ATAN2 both have obvious logical reasons why the
two arguments should be the same kind. In general, any mathematical
function like ATAN2 will determine the kind of its results from the kind
of its arguments, and in those cases the Fortran standards require the
kinds match. (DOT_PRODUCT is an interesting exception to this; it
mimics the multiplication operator.)
(Note that, in some cases, we already have a GNU extension that allows
mismatched kinds by promoting the smaller argument to the kind of the
larger in the front end, before making the library call.)
In cases where there is no mathematical reason for the kinds to be the
same, even F95 makes no such restriction: see ISHFTC (no restriction on
kinds of SHIFT and SIZE args), MVBITS (FROMPOS, LEN, and TOPOS args),
RESHAPE (SHAPE and ORDER args), and SPREAD (DIM and NCOPIES).
The more relevant question, though, is system-call procedures. In F2003:
DATE_AND_TIME requires default integers.
GET_COMMAND and GET_COMMAND_ARGUMENT require default integers.
GET_ENVIRONMENT_VARIABLE requires default integers.
RANDOM_SEED requires default integers.
SYSTEM_CLOCK has two integer and one integer or real argument, with no
kind restrictions in F2003. In F95, SYSTEM_CLOCK requires default integers.
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.
I don't know that this is actually true, for the relevant intrinsics
that match the ones we're talking about. See above, where SYSTEM_CLOCK
is the only system-call-like procedure that accepts non-default integer
arguments in F2003.
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.
Yes. However, I think that it is a quite unwise idea to make design
decisions that (a) will have to be fixed when we start getting serious
about supporting F2003, and (b) are gratuitiously different from the way
the standard features work.
Thus, I would very strongly suggest that we define the GNU intrinsics
such that they fit into the patterns of the existing standard
intrinsics. Specifically, system-call procedures with integer arguments
should either:
* accept only default-integer arguments
or:
* accept any kind of integer argument, without requiring multiple
arguments to be the same kind.
I have no strong bias towards either of these, but I do think that for
the latter option it is probably best to implement it by type-converting
everything to some default kind (either integer(4), integer(8), or
default integer) in the front end, and converting the results back out
afterwards as needed.
In any case, I don't think that providing library implementations for
kinds other than i4 and i8 is a good thing for these procedures.
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.
I don't think F2003 will make us rethink very much here; I honestly
don't see a lot that's changed -- at least, not a lot that's changed
compared to some stuff we already allow as GNU extensions.
- Brooks