[PATCH 1/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Tobias Burnus
burnus@net-b.de
Tue Mar 4 17:42:00 GMT 2014
Ilmir Usmanov:
> OpenACC 1.0 support to fortran FE -- core.
>
> + case OMP_LIST_USE_DEVICE:
> + if (n->sym->attr.allocatable)
> + gfc_error ("ALLOCATABLE object '%s' of polymorphic type "
> + "in %s clause at %L", n->sym->name, name, &code->loc);
That check is wrong (copy & paste bug): Either you only want to check
for allocatable - then it might be nonpolymorphic. Or you want to check
for polymorphism - then the check needs to be extended.
> + if ((sym->ts.type == BT_CLASS || sym->ts.type == BT_ASSUMED)
> + && sym->attr.allocatable)
> + gfc_error ("ALLOCATABLE object '%s' of polymorphic type "
> + "in %s clause at %L", sym->name, name, &loc);
Due to the idiosyncratic way BT_CLASS is implemented, this allocatable
check won't work. You have to use:
(sym->ts.type == BT_ASSUMED && sym->attr.allocatable)
|| (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
&& CLASS_DATA (sym)->attr.allocatable)
You may need to add a similar check also in place of
sym->attr.allocatable and sym->attr.pointer (there:
CLASS_DATA(sym)->attr.class_pointer - instead of attr.pointer) for the
other checks, if a BT_CLASS can occur. (Thus: if(ts.type != BT_CLASS &&
...) || (ts.type == BT_CLASS && ...)
The extra CLASS_DATA(sym) ensures that one doesn't deref a NULL pointer,
which can happen if an error has occurred. That shouldn't be required in
trans*.c, but at least in resolve.c it can happen that the code is
reached, even though an error has been printed before.
> +static void
> +resolve_oacc_cache (gfc_code *)
> +{
> + // Nothing to do yet
> +}
Shouldn't you use:
sorry("OpenACC cache not yet implemented");
or something like that?
Otherwise, it looks good to me.
Tobias
More information about the Fortran
mailing list