This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gomp4] Questions about "declare target" and "target update" pragmas

On Wed, Jan 22, 2014 at 07:51:51PM +0400, Ilya Verbin wrote:
> I have 2 questions concerning OpenMP 4.0 specification.
> 1.  Do I understand correctly that every "declare target" directive should be
> closed with "end declare target"?  E.g. in this example GCC marks both foo1 and
> foo2 with "omp declare target" attribute:
> #pragma omp declare target
> int foo1 () { return 1; }
> int foo2 () { return 2; }
> /* EOF */

Yes, this is invalid.

> Shouldn't the frontend issue an error message that there is "declare target"
> without corresponding "end declare target"?

I guess so, e.g. the C FE has current_omp_declare_target_attribute,
supposedly it could check it after parsing the whole file and if it is
non-zero at the end, complain.

> 2.  Do I understand correctly that the "target update" directive can be used
> outside the "target" or "target data" regions?  E.g. this example should
> print '2' (and it prints '2' while building with icc):
> #pragma omp declare target
> int G = 1;
> #pragma omp end declare target
> int main ()
> {
>   G = 2;
>   #pragma omp target update to(G)
>   G = 3;
>   int x = 0;
>   #pragma omp target
>     {
>       x = G;
>     }
>   printf ("%d\n", x);
> }

This can print 3 (if doing host fallback or device shares address space
with host), or 2 (otherwise).  It shouldn't print 1 ever, and yes,
the target update is then well defined.  All variables from omp declare
target are allocated on the device sometime before
the first target data/target update/target region; given that they will
be allocated in the data section of the target DSO, they actually just need
to be registered with the mapping data structure when the DSO is loaded.

> If it is acceptable, then GOMP_target_update should also map variables that
> wasn't mapped.

No, the target DSO initialization should use the tables we've talked about
to initialize the mapping.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]