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

--- Comment #11 from Benjamin Schulz <schulz.benjamin at googlemail dot com> ---
But it is interesting... indeed the problem also seems to cover other areas. 

For example, this here would compile:

int main()
{

double data[20];

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



This here not:


#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;
    }
}


The code should do exactly the same but does not compile just because the data
variable was put into a struct as a member variable...


as you can see in this example, that behavior seems ehm, not to be quite
reasonable....


When you have a struct with hundreds of members it is rather inconvenient to
unpack them all into hundred separate variables before one makes the loop...


I think that this statement:

"If a list item in a map clause is a variable of structure type then it is
treated as if each structure element contained in the variable is a list item
in the clause." 

from the map clauses should hold generally in such a case.

The wording for list statements:

"Unless otherwise specified, a variable that is part of an aggregate variable
must not be a variable list item or an extended list item" in conjunction with
"A variable list item is a variable" 

would imply that "all member variables of aggregate types are forbidden"...



In case of the gpu, it makes sense that the map alloc construct requires you to
allocate on the host so that you can download.


But often one wants temporary data, purely on gpu. Then target_alloc and
is_device_ptr are the only route.

To forbid struct members in is_device_ptr means that you then need to abandon
structs and classes entirely and just work with raw arrays and non aggregate
types... 


This does work, for very simple things, so to say, it is convenient unless your
structs and classes have hundreds of members....

Also it is inconvenient in a case like C where you need structs to build your
own tensors

Reply via email to