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

["David S. Miller" <davem at redhat dot com>]

The following reply was made to PR target/8087; it has been noted by GNATS.

From: "David S. Miller" <davem@redhat.com>
To: roger@eyesopen.com
Cc: davem@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        ghazi@caip.rutgers.edu, rth@redhat.com, jakub@redhat.com,
        gcc-gnats@gcc.gnu.org
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in
 execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Mon, 07 Oct 2002 11:20:31 -0700 (PDT)

    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.