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: Richard Henderson <rth at redhat dot com>
- Cc: <gcc-bugs at gcc dot gnu dot org>, <gcc-prs at gcc dot gnu dot org>, <ghazi at caip dot rutgers dot edu>, <davem at redhat dot com>, <jakub at redhat dot com>, <gcc-gnats at gcc dot gnu dot org>
- Date: Mon, 30 Sep 2002 18:03:59 -0600 (MDT)
- Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures inexecute/20020720-1.c w/-m64 or on sparcv9/sparc64
> One is sort of meaningless all on its own. You have to know what
> sort of comparison is going to be used with it.o
> Hum, actually that's true with NaN and UNORDERED as well.
> I.e. this is all bogus for COMPARE targets.
My apologies to that sparc64 maintainers. The HP-UX solution is
indeed inapplicable for COMPARE targets.
I also now realize my mistake trying to analyze this problem. I was
running "cc1" with "-m64 -O2" whilst debuging in gdb, as these were
the same flags I used to run gcc. The problem is that gcc also
passes "-mcpu=v9" to cc1, and this flag is required to exhibit
the problem. It turns out that its the sparc64's constant pool
handling that hides the optimization, rather than the optimization
triggering and not being representable in the machine description.
Sorry for the confusion. You can tell I haven't done much work
with gcc on sparc/solaris.
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833