This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: reworking intrinsic procedures
On Mon, Mar 05, 2007 at 06:13:35AM +0100, FX Coudert wrote:
> >Well, I think we should do like you did in gfc_resolve_flush().
> >
> > ts.type = BT_INTEGER;
> > ts.kind = gfc_default_integer_kind;
> > n = c->ext.actual->expr;
> > if (n != NULL && n->ts.kind != ts.kind)
> > gfc_convert_type (n, &ts, 2);
> >
> > name = gfc_get_string (PREFIX ("flush_i%d"), ts.kind);
> > c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
>
> That still requires 2 library functions. We could reduce that by
> using a single kind for most cases.
Yes, I realize there are 2. My problem with the casting to/from
argument types in trans-intrinsics.c (that you proposed elsewhere)
is that it can get messy. In particularly, since we don't have a
giant switch for the intrinsic subroutines like we do with functions
(see gfc_conv_intrinsic_function), we need to explicitly deal with
each intrinsics subroutine. At moment, iresolve.c maps everything
with possible conversions to functions in the library, and we don't
need to mess around with type conversion trans-intrinsics.c.
> In fact, the only problem I can see with the one-kind-for-all scheme
> is when some option changes the bit precision of the long integer
> kind. Can that happen? (meaning, an option without which you have an
> integer(kind=8), and with which this kind disappears)
I don't think this can happen. -fdefault-integer-8 changes the
default integer kind from 4 to 8, but the kind for INTEGER(8)
remains unchanged.
--
Steve