https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119474
--- Comment #1 from Andrew Stubbs <ams at gcc dot gnu.org> ---
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?
