Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

[Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>]

Ilmir Usmanov wrote:
> On 19.03.2014 23:35, Thomas Schwinge wrote:
> > Do you intend to support loop constructs that are not nested in a
> > parallel or kernels construct?  As I'm reading it, the specification is
> > not clear on this.  (I guess I'll raise this question with the OpenACC
> > guys.)
>
> Yes, I do. There are three reasons to support OpenACC loop directive
> without enclosing construct: 
> 1) The spec doesn't require the directive to be inside of a construct.
> 2) PGI compiler does support this.
> 3) GCC OpenMP implementation supports loop construct without parallel.
>
> However, I agree that there no sense to use OpenACC loop without a
> construct. So, should there be a warning, perhaps? 

Could it happen that such a loop becomes active due to inlining, such
as:

f() __attribute__((inline)) {
#pragma acc loop
for (...) {
   ...
}

...

#pragma acc parallel
{
  f()
}


Or is that not possible? With OpenMP I surely used a similar code, but
there one does no have to generate special accelerator code. I know that
the Cray compiler does even LTO inlining with OpenACC, which permits to
call functions in a kernels/parallel section, which are defined in a
different file. [That is without using the OpenACC 2.0 features of
specially tagging a function as one which also runs on accelerators.]
However, I do not know whether Cray or other OpenACC compilers will
honor the 'loop' in this case. I would assume that they do, but I
haven't tested it.

Tobias