[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 #12 from Benjamin Schulz <schulz.benjamin at googlemail dot com> ---
a workaround that compiles is this:


#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());

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

}



but does gcc then recognize that x, which was given to is_device_ptr is just an
alias for t.data in the loop?


If it does, then one could use this, as long as the member variables are used
in the loop, where the code should be readable. Even though that unpacking
before the loop still looks unnecessary and strange if it involves hundreds of
members...

If one looks at this statement from openmp:

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"

this reduces logically to: 

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


That makes not sense logically. "Why not just say, members of aggregate
variables are forbidden?"

Perhaps the people who wrote the first sentence did not understand what
variable list item mean in openmp mean and confused this with some pythonic
lists that can have variable size...

I really think that this is the case here, and that one should interpret this
as to forbid extensible arrays... because only then the statement makes sense.
If someone were to try to put a type of varying size, like the stl vector into
is_device_ptr, then it could of course not compile correctly, as within the
loop, more deviceptrs would be dynamically added... I think this is what they
meant with this wording.. 

They did not want to forbid member variables of structs or classes, because
that would make no sense to write it in such an involved way. If they wanted to
forbid member variables, they would write "member variables and member arrays
of aggregate types are not permitted" or something. Instead, it seems they
wanted to forbid vectors with this wording..

At least this is my interpretation of the wording of this standard...