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: Richard Henderson <rth at redhat dot com>
- To: 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, nobody at gcc dot gnu dot org, davem at redhat dot com, jakub at redhat dot com, roger at eyesopen dot com, gcc-gnats at gcc dot gnu dot org
- Date: Mon, 30 Sep 2002 16:24:21 -0700
- Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
- References: <20020930225204.8517.qmail@sources.redhat.com>
On Mon, Sep 30, 2002 at 10:52:04PM -0000, davem@gcc.gnu.org wrote:
> The problem is, it's REALLY REALLY expensive to set the
> float condition codes to a constant value (two FPU synchronizing
> memory operations).
Not really. Zero is easy:
fzeros %f0
fnot1s %f1, %f0
fcmps %fcc0, %f1, %f0
(note that ~0 is a NaN). 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.
r~