target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[David S. Miller]

   From: Roger Sayle <roger@eyesopen.com>
   Date: Mon, 7 Oct 2002 12:04:10 -0600 (MDT)

   The sparc64 backend represents a load from the constant pool as:
   
   (mem/u/f:DF (lo_sum:DI (reg/f:DI 110)
                          (symbol_ref/u:DI ("*.LLC0"))) [2 S8 A64]
   
So does sparc32, at different stages of the compilation, for
example for something simple like "double foo(void){return 0.0;}"
the foo.c.00.rtl has:

(insn 11 10 13 (set (reg/f:SI 109)
        (lo_sum:SI (reg:SI 110)
            (symbol_ref/u:SI ("*.LLC0")))) -1 (nil)
    (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LLC0"))
        (nil)))


Which has the SYMBOL_REG inside of a LO_SUM construct.

Note, the "/u" flag means unchanging which means it is
a constant pool SYMBOL_REF.

   The problem is that the code in "avoid_constant_pool_reference"
   in simplify-rtx.c (line 149), assumes that constant pool references
   are of the form "(mem (symbol_ref ...))".  Indeed the macro
   CONSTANT_POOL_ADDRESS_P assumes that it is always passed a naked
   symbol_ref.
   
   A possible fix may be to extend this test is also allow the constant
   pool to be indexed via LO_SUM.  Something like:
   
This looks perfectly fine to me.  I think it will improve code
on all platforms that use LO_SUM, not just sparc64 and sparc32.