[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1902280132030.8764@key0.esi.com.au>
Date: Thu, 28 Feb 2019 02:38:44 +1100 (AEDT)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: FE Exception triggered by comparison
On Wed, 27 Feb 2019, Alexander Monakov wrote:
>> 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?
I would love to be proved wrong, but if you want something that is safe
from generating an exception with an signalling NaN, you need to do this.
For qNaN stuff, I personally normally do
if (x != x) /* then 'x' is an NaN */
but I find that isnan(x) does not expand to anything like this. Anyway,
when I tried the code below, I was just shocked.
#include <math.h>
#include <stdio.h>
main()
{
double x = 5.0;
x -= x, x /= x;
printf("what %s\n", isnan(x) ? "yes" : "no!");
return(0);
}
Looking at the assembler, there is a subroutine call to __isnan. Awful!
>>> 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++)
You are correct. Markus was reading the standard incorrectly I believe. Or
maybe my explanation of what I was trying to do was poor and Markus simply
misunderstood what I was trying to say!
>> 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.
Wonderful. Thanks for that information. GCC 8 is on my list of updates but
I have yet to get around to it. I will rerun my tests against that.
I do lament that I have to resort to using
isless()
macro and friends to do a comparison in C/C++ without triggering an IE. It
really does seriously compromise the readability of code. It would be nice
if we had operators like
~<=
instead of having to use the long-winded
islessequal
Than again, everybody wants their own succint operators and there are only
a limited number of characters to exploit. I think Professor Kahan asked
for
!<
for 'not less than' over 20 years ago and we have not seen any movement
on that front.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
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.
