[Bug target/119474] GCN 'libgomp.oacc-c++/pr96835-1.C' ICE 'during GIMPLE pass: ivopts'

[rguenth at gcc dot gnu.org]

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.