From: Damian McGuckin <damianm@esi.com.au>
To: musl@lists.openwall.com
Subject: Re: FE Exception triggered by comparison
Date: Thu, 28 Feb 2019 02:38:44 +1100 (AEDT) [thread overview]
Message-ID: <alpine.LRH.2.02.1902280132030.8764@key0.esi.com.au> (raw)
In-Reply-To: <alpine.LNX.2.20.13.1902271651450.30425@monopod.intra.ispras.ru>
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
next prev parent reply other threads:[~2019-02-27 15:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-24 13:28 Damian McGuckin
2019-02-24 17:12 ` Markus Wichmann
2019-02-24 19:25 ` Szabolcs Nagy
2019-02-24 20:04 ` Jens Gustedt
2019-02-24 21:50 ` Damian McGuckin
2019-02-25 5:21 ` Damian McGuckin
2019-02-25 15:51 ` Markus Wichmann
2019-02-26 3:55 ` Damian McGuckin
2019-02-27 14:14 ` Alexander Monakov
2019-02-27 15:38 ` Damian McGuckin [this message]
2019-02-27 16:00 ` Alexander Monakov
2019-02-27 16:09 ` Damian McGuckin
2019-02-27 16:14 ` Markus Wichmann
2019-02-27 16:20 ` Damian McGuckin
2019-02-28 1:07 ` Damian McGuckin
2019-02-28 1:27 ` Rich Felker
2019-02-28 2:28 ` Damian McGuckin
2019-02-27 16:32 ` Alexander Monakov
2019-02-27 16:42 ` Rich Felker
2019-02-27 17:08 ` Szabolcs Nagy
2019-02-27 17:14 ` Alexander Monakov
2019-02-27 17:26 ` Rich Felker
2019-02-27 19:36 ` Szabolcs Nagy
2019-02-27 19:48 ` Alexander Monakov
2019-02-27 20:16 ` Szabolcs Nagy
2019-02-27 20:35 ` Rich Felker
2019-02-27 21:03 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.02.1902280132030.8764@key0.esi.com.au \
--to=damianm@esi.com.au \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).