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 in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- To: roger at eyesopen dot com, rth at redhat dot com
- Cc: davem at redhat dot com, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, jakub at redhat dot com
- Date: Wed, 2 Oct 2002 10:46:13 -0400 (EDT)
- Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
- References: <Pine.LNX.4.33.0209301755160.10986-100000@www.eyesopen.com>
> From: Roger Sayle <roger@eyesopen.com>
>
> > 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.
So what does that mean with respect to addressing the testcase?
Fixable? XFAIL it?
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu