On Fri, Dec 08, 2023 at 03:28:59PM +0100, Tobias Burnus wrote:
> This patch fixes the issue:
>
> int a[100];
> p = &a[0];
>
> #pragma omp target map(a)
> p[0] = p[99] = 3;
>
> where 'p' is predetermined firstprivate, i.e. it is firstprivatized
> but its address gets updated to the device address of 'a' as there is
> associated storage for the value of 'p', i.e. its pointee.
I think the above is invalid even in TR12.
> OpenMP Spec:
>
> The first feature is not new, but I have not checked the wording in 4.5 or
> 5.0;
> it might be that older versions only required it to work for storage mapped
> before
> the current taget directive. But at least TR12 is very explicit in permitting
> it
> and the (nonpublic) issue which lead to the 5.1 change also uses this. (See
> PR.)
> (The second feature is definitely new in OpenMP 5.1.)
>
> TR12 states in "14.8 target Construct" [379:8-10]:
>
> "[C/C++] If a list item in a map clause has a base pointer that is
> predetermined firstprivate
> (see Section 6.1.1) and on entry to the target region the list item is
> mapped, the firstprivate
> pointer is updated via corresponding base pointer initialization."
The list item (a) in the above case doesn't have a base pointer, but base
array. See the glossary. So, the rule would be about something like
int *p = ...;
#pragma omp target map (p[20:100]) or similar, not about an array and an
unrelated pointer.
Jakub
