[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