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

[Roger Sayle]

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

From: Roger Sayle <roger@eyesopen.com>
To: "David S. Miller" <davem@redhat.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, 7 Oct 2002 12:25:48 -0600 (MDT)

 > 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.
 
 Indeed.  The difference is that by foo.c.18.combine the constant
 pool reference has been optimized away on sparc32, but it isn't
 if "-m64" is specified or on sparc64.
 
 > Note, the "/u" flag means unchanging which means it is
 > a constant pool SYMBOL_REF.
 
 Thanks.
 
 >    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.
 
 Excellent.  I'll perform the usual bootstraps and regression tests
 on sparc-sun-solaris2.8, and then post the patch to gcc-patches
 today or tomorrow.
 
 Roger
 --