Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.