[RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis

[Roger Sayle]

Hi John David,
> This test fails on hppa64-hpux at -O3.  The function foo is correctly
> optimized but the inline copy in main is not.  After the life pass, the
> abs operation is gone and we have this rtl:
>
> (insn 16 15 27 0 800003ffeffbb960 (set (reg/v:DF 69)
>         (mem/u/f:DF (reg/f:DI 70) [2 S8 A64])) 110 {*pa.md:3107} (insn_list 15 (nil))
>     (expr_list:REG_DEAD (reg/f:DI 70)
> 	(expr_list:REG_EQUAL (const_double:DF 0 [0x0] 0 [0x0] -9223301672405565440 [0x80003fff00000000])
> 	    (nil))))
>
> (insn 27 16 28 0 800003ffeffbb9c0 (set (reg:CCFP 0 %r0)
> 	(lt:CCFP (reg/v:DF 69)
> 	    (const_double:DF 0 [0x0] 0 [0x0] 0 [0x0]))) 1 {*pa.md:621} (insn_list 16 (nil))
>     (expr_list:REG_DEAD (reg/v:DF 69)
> 	(expr_list:REG_EQUAL (const_int 0 [0x0])
> 	    (nil))))
>
> (jump_insn 28 27 54 0 800003ffeffbb9c0 (set (pc)
> 	(if_then_else (ne (reg:CCFP 0 %r0)
> 		(const_int 0 [0x0]))
> 	    (label_ref 31)
> 	    (pc))) 66 {*pa.md:2159} (insn_list 27 (nil))
>     (expr_list:REG_DEAD (reg:CCFP 0 %r0)
> 	(expr_list:REG_BR_PROB (const_int 3000 [0xbb8])
>             (nil))))
>
> >From the discussion, it appears that combine should know how to optimize
> this rtl (3 insns?) but apparently there is a problem.  However, the
> problem in this case isn't the abs optimization.


This is very interesting!  Notice the REG_EQUAL note on instruction
27, the compiler has determined that the condition flags are always
false (i.e. that 1.0 is not less than 0.0)!  I'd be surprised that
with this information the conditional branch survives the rest of
compilation.

I've tried reproducing this problem on a cross compiler from
i686-pc-cygwin to hppa64-hp-hpux11.00, but I've been unable to
reproduce the behaviour as "foo" refuses to be inlined at -O3.
Is the inliner a known deficiency of cross-compiling from 32bit
hosts to 64bit targets?

One observation is that the .s files still contain references
to ".IMPORT link_error,ENTRY" even though link_error is never
referenced or called in the generated code.  I didn't build a
full hppa64 toolchain, so I've no idea if this is the issue.

Do I have hppa64-hp-hpux11.00 correct as the target triple?
Using "--target=hppa64-hpux" as described in your e-mail fails
at configure time with an unsupported target error, but the
test results for hppa64-hp-hpux11.00 don't show this failure
http://gcc.gnu.org/ml/gcc-testresults/2002-08/msg00641.html

Roger
--