[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail to compile (note that map works in this case)

[schulz.benjamin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753

--- Comment #13 from Benjamin Schulz <schulz.benjamin at googlemail dot com> ---
I suspect that the statement, which Tobias cites, does not forbid member
variables of structs.

I think that thid is an incorrect interpretation of the standard.

What they probably wanted to forbid was this:

assume you have an stl vector like

std::vector<size_t> y(20,0);

then, y[1] is a member of an aggregate type (the stl vector) and y[1] is a
variable list item (as it is commonly called as such in computer science),
since the stl vector has add and delete methods and is of variable size.
Furthermore, y[1] is surely a variable. 

So the conditions of the OpenMP statement that Tobias cites would hold for
y[1].

But of course, it makes no sense to put y[1] into OpenMP clauses like 

#parallel for shared(y[1]) or 
#pragma omp target teams distribute is_device_ptr(y[1])


since if in the following loop someone would call erase on the vector y, then
y[1] would cease to exist but the contents of these pragmas must be known to
exist at compile time...



On the other hand, if you would use the OpenMP document solely as definition,
then the statements:

1) Unless otherwise specified, a variable that is part of an aggregate variable
must not be a variable list item or an extended list item" 

2) "A variable list item is a variable"

would reduce to 

"Unless otherwise specified, a variable that is part of an aggregate variable
must not be a variable", 

which contradicts itself, 

Therefore, I do not think this interpretation that gcc uses to base its
behavior on is correct in that case. 


It would forbid to use struct members and class in many constructs, where
everything is  known at compile time, and for no apparent reason, even if they
are just for shared variables in a loop and even if the data in the structs is
just read! by the threads.


In contrast, the OpenMP statement makes sense once you interpret the term
"variable list item" here as it is usually understood in computer science, as
shown above.



In a code snippet like:

#include <omp.h>
struct mystruct
{
    double data[20];
};


int main()
{
mystruct t;

#pragma omp parallel for shared(t.data)
 for(int i=1;i<20;i++)
    {
        t.data[i]=20;
    }
}



or 

#include <omp.h>
struct mytensor
{
int *strides;
int *extents;
double *data;
};

int main()
{
mytensor t;
t.data=(double*)omp_target_alloc(sizeof(double)*20,omp_get_default_device());

#pragma omp target teams distribute is_device_ptr(t.data)
 for(size_t i=1;i<20;i++)
    {
        t.data[i]=20;
    }

}


which do not compile, there are no items of that kind of variable lists which I
think OpenMP wanted to refer to here.