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