This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: target/8087: sparc-sun-solaris2.7 C testsuite failures inexecute/20020720-1.c w/-m64 or on sparcv9/sparc64
- From: Roger Sayle <roger at eyesopen dot com>
- To: "David S. Miller" <davem at redhat dot com>
- Cc: <davem at gcc dot gnu dot org>, <gcc-bugs at gcc dot gnu dot org>, <gcc-prs at gcc dot gnu dot org>, <ghazi at caip dot rutgers dot edu>, <rth at redhat dot com>, <jakub at redhat dot com>, <gcc-gnats at gcc dot gnu dot org>
- Date: Mon, 7 Oct 2002 12:25:48 -0600 (MDT)
- Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures inexecute/20020720-1.c w/-m64 or on sparcv9/sparc64
> 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
--