Re: Latent bug in update_equiv_regs?

[Jeff Law <law at redhat dot com>]

On 08/20/09 02:45, Richard Guenther wrote:
> It looks indeed bogus.  Do you have a testcase at hand?
>    
Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu.  
Find MAIN__.omp_fn.2 in the .expand dump.

Within that function, you're looking for this sequence of insns:



;; D.3137_29 = REALPART_EXPR <.omp_data_i_55(D)->c>;

(insn 242 241 0 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 0 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))


This doesn't cause a libgomp testsuite failure in the mainline because 
(reg:SF 74) gets a hard reg and thus reload doesn't utilize the bogus 
REG_EQUIV note that eventually gets added to insn 242.

Jeff

Attachment: reduction1.f90
Description: Text document