[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1902271651450.30425@monopod.intra.ispras.ru>
Date: Wed, 27 Feb 2019 17:14:55 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: FE Exception triggered by comparison
On Tue, 26 Feb 2019, Damian McGuckin wrote:
> > Yet another problem brought to you by premature optimization. What you
> > want to know is if a certain number is NaN. There's a perfectly
> > acceptable idiom for that:
> >
> > if (isnan(x)) {
> > }
>
> I understand this. But, at least on an X86 architecture, that involves a
> write-to+read-from memory and I want to avoid that.
I don't understand this claim. With both SSE and x87 this should amount to
comparing a register with itself and testing flags. Can you elaborate?
> > Well, sorry, but these instructions do not work that way. Any operation
> > on a NaN, including comparison, even comparison for equality, will raise
> > IE, at least if it is an sNaN.
(for sNaNs, sure, but notably for qNaNs comparisons for equality, as opposed
to ordered comparisons, should not raise "invalid" in C and C++)
> However, on experiments on GCC, the if/else/else/else above does not raise an
> IE. Is this an optimizer bug?
You're probably seeing the long-standing bug in gcc x86 backend where it would
emit 'ucom'-kind instructions for both ordered and equality comparisons. It
appears to be finally fixed starting from GCC 8.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
