Re: Latent bug in update_equiv_regs?

[Jeff Law <law at redhat dot com>]

On 08/19/09 18:48, Ian Lance Taylor wrote:
> Jeff Law<law@redhat.com>  writes:
>
>    
> > You're right.  This should have been rejected by validate_equiv_mem,
> > but isn't because the two memory references are in different alias
> > sets.
> >
> > You can see this in the mainline sources configured for
> > i686-pc-linux-gnu by compiling
> > libgomp/testsuite/libgomp.fortran/reduction1.f90 with -O3 -fopenmp
> >
> > In the .expand dump we have:
> >
> > (insn 242 241 243 47 j.f90:138 (set (reg:SF 74 [ D.3137 ])
> >          (mem/s:SF (plus:SI (reg/f:SI 247 [ .omp_data_i ])
> >                  (const_int 32 [0x20])) [2 .omp_data_i_55(D)->c+0 S4
> > A64])) -1 (nil))
> > [ ... ]
> >
> > (insn 247 246 248 47 j.f90:138 (set (mem/s:SF (plus:SI (reg/f:SI 247 [
> > .omp_data_i ])
> >                  (const_int 32 [0x20])) [13 S4 A64])
> >          (reg:SF 351)) -1 (nil))
> >
> > As you can see we've got different alias sets on the two MEMs.   This
> > could be an expansion bug, f95 bug, or a bug in one of the SSA
> > optimizers.   Ugh.
> >      
> My first guess would be our current ooglie booglie: invalid stack slot
> sharing in cfgexpand.c.
>    
I don't think that's the case.  I hacked up partition_stack_vars to not 
share anything and still get the same failure.

Jeff