https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119474
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andrew Stubbs from comment #1) > In the -O1 case, the problem seems to be that the "ivopts" pass has > identified an item-in-an-array-in-a-struct as the IV, and that struct is in > a different address space: > > Type: REFERENCE ADDRESS > Use 0.0: > At stmt: _9 = v1.values_[i_38]; > At pos: v1.values_[i_38] > IV struct: > Type: int * > Base: (int *) (unsigned long) &v1 > Step: 4 > Object: (void *) (&v1) > Biv: N > Overflowness wrto loop niter: Overflow > > When it tries to calculate the base address-of operator, it observes the > type of "values_[i_38]", which doesn't have anything like an address space. > > In the -O2 case, the problem seems to be the same, except that it's > happening in the "vect" pass: the compiler attempts to create a "vectp" to > match &v1, but doesn't propogate the address space correctly. > > Question: are we just missing address-space handling in a bunch of places, > or is the OpenACC lowering producing non-canonical IVs somehow? For sure the former. Where exactly it goes wrong needs to be investigated, in IVOPTs it should be add_iv / add_candidate to look at (_lots_ of callers). I can have a look, but if it is urgent you're invited to try as well.
