This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Latent bug in update_equiv_regs?
On Thu, Aug 20, 2009 at 2:33 AM, Jeff Law<law@redhat.com> wrote:
> On 08/19/09 17:46, Ian Lance Taylor wrote:
>>
>> My understanding is that that scenario is supposed to not happen because
>> update_equiv_regs is only supposed to equate a register and a memory
>> location in the specific cases where that is OK. ?It's not no_equiv that
>> is supposed to fix this, the equivalence should only be created when it
>> will always be OK.
>>
>> So I think you need to explain more about why the equivalence was
>> created.
>>
>> Ian
>>
>
> 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.
It looks indeed bogus. Do you have a testcase at hand?
Richard.
> Thanks,
> jeff
>
>
>
>