Re: [PATCH 2/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Ilmir Usmanov <i dot usmanov at samsung dot com>]

Hi Tobias!

On 10.02.2014 03:10, Tobias Burnus wrote:
> Shouldn't you also reject polymorphic types ("BT_CLASS" and 
> "BT_ASSUMED")? [BT_CLASS = "class(derived_type_name)" or "class(*)"; 
> BT_ASSUMED = "type(*)"]
>
> > +      if (n->sym->attr.pointer)
> > +        gfc_error ("POINTER object '%s' in %s clause at %L",
> > +                   n->sym->name, name, &code->loc);
>
> Actually, here and probably elsewhere: Do you need to take care of 
> derived-type components? I mean something like
>    clause(derived_type%comp)
>
> Do you also need to reject AS_ASSUMED_RANK (new since Fortran 
> Technical Specification ISO/IEC TS 29113:2012)? I mean code like:
>
>    subroutine foo(x)
>      integer, DIMENSION(..) :: x
>      ... openacc_clause(x)
>
> Side note: One should also check how OpenMP handles those.
I think we should reject assumed size, assumed shape and assumed rank 
variables, as OpenMP does.

> > +      case OMP_LIST_DEVICEPTR:
> > +        if (n->sym->attr.pointer)
> > +          gfc_error ("POINTER object '%s' in %s clause at %L",
> > +                     n->sym->name, name, &code->loc);
>
> Talking about pointers, you probably also want to reject Cray pointers 
> (attr.cray_pointee - and cray_pointee). [One should also check what 
> OpenMP does; I think it does handle it correctly.]
I agree, currently my implementation does not handle Cray pointers 
correctly, will fix.

> And another point: I think you have to check whether the argument is a 
> named constant (PARAMETER, attr.flavor == FL_PARAMETER), I think those 
> you cannot put them there either.
>
> What happens if you try to use a literal such as "deviceptr(5)"?
Both parameter and literal are rejected.
By the way, PGI compiler accepts parameters with warning, CAPS silently 
accepts. I think, we also should support parameters with warning.

> > +          resolve_oacc_positive_int_expr (el->expr, "TILE");
> > +          if (el->expr->expr_type != EXPR_CONSTANT)
> > +            gfc_error ("TILE requires constant expression at %L", 
> > &code->loc);
>
> Is the following permitted: "tile(4+5)"? If so, do you need to call 
> gfc_simplify_expr() as some point? (Or is this already done at some 
> point?)
Yes, the syntax is allowed, but ...
CAPSCompilers-3.4.1/bin/hmpp: [Error HP0112] tile.f95:30: Syntax error: 
expecting ')'
!$acc  parallel loop collapse(1+ 1)

CAPS compiler doesn't support this. But PGI does.

There is no need to simplify expression since it is constant anyway. The 
simplification is done during match stage (gfc_match_expr calls gfc_add).

--
Ilmir.