From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13882 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Damian McGuckin Newsgroups: gmane.linux.lib.musl.general Subject: Re: FE Exception triggered by comparison Date: Thu, 28 Feb 2019 02:38:44 +1100 (AEDT) Message-ID: References: <20190224192511.GZ21289@port70.net> <20190224210438.6980bd87@inria.fr> <20190225155109.GB28106@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="52713"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) To: musl@lists.openwall.com Original-X-From: musl-return-13898-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 27 16:39:03 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gz1IV-000Dd5-I4 for gllmg-musl@m.gmane.org; Wed, 27 Feb 2019 16:39:03 +0100 Original-Received: (qmail 25768 invoked by uid 550); 27 Feb 2019 15:39:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 25746 invoked from network); 27 Feb 2019 15:38:59 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13882 Archived-At: 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 #include 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