From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13864 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: FE Exception triggered by comparison Date: Mon, 25 Feb 2019 16:51:09 +0100 Message-ID: <20190225155109.GB28106@voyager> References: <20190224192511.GZ21289@port70.net> <20190224210438.6980bd87@inria.fr> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="198206"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13880-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 25 16:52:28 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 1gyIYL-000pTY-VN for gllmg-musl@m.gmane.org; Mon, 25 Feb 2019 16:52:26 +0100 Original-Received: (qmail 5637 invoked by uid 550); 25 Feb 2019 15:52:23 -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 5619 invoked from network); 25 Feb 2019 15:52:23 -0000 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:Ngz1kaFsoIfsEdkujph7Zyrjj825DWOwJ9FWokKnC5nMn5+WGrO phbwZZ+r+n6GWGp23+m89P4tuspaSn6Mh/rrqjAQxI56Fp39UKHWNYllpwUj+blolV3hdf/ S6xMr0ngKiobkd/k/YMumWmhzPexBk0nDJym27CVOaI9cm2O2UvMMFoTQaTR0vCB1lT0t6G flG5YuwsuqNEunuEFZ7Bg== X-UI-Out-Filterresults: notjunk:1;V03:K0:34dd+AI1ErE=:JcFpeenbFZ4JWGCKahD/3Z nn9Gvd7mDAf+G6DtWoKPXGscxAPEfi/ig+n1OpvWip2SoGsQWjL8h2T/kwW6dk+OhUElu6SvQ mfsyvI8wrrD/wmBouvZDo54ptwgn4YBL3tOgjuKx3VT1Zp1iREUlbxm8hYXiRsc8+gzXsoYFy q/E+fGjg1tpDi7Nr6gwmguO1vamdQ9Q4Ey07LL8Yf/lyxZ7V2bS9bLZfJGPdmMsghHHxaKj2Q aXhQksNIRD9Z/i0T8EqQDfY08PeCeMg0yv5MHDEDcbzBx8rZU507tticvNUFjHr2WEAiRIz0p 403BZASTpVsjZfPHpiC/nladUjhymWOJuRftHhWxppmM827FVMKx28ntuySwyrzWvz7evtxaw x4p4b9BLmritONSYkgtIrlRXkuvvdFYal7KCIlIaa4VZhiz5/Bweyv9qw5beJW39QT/h080CS QfBgwT78TYJ4uz3rTHy0CJEuX66ByyDmoOvCLXLubIUo1GgzpOvSM36Wosv7GR5x1HtHlpYbA S8vzSna188ps8qqQuWrm6ChiRLTGcmVJdvALh/Nmv1+ofwG5O8s4yhgPza57z8IJGYM1D1AZE qGx39F5Du65SZPFGXryipzH3HyhG+d9hx8F5zd5gbo7RoeTTsB2Nl+PDC5VIIoVrsTQIg9Kct H0SVoCXrs55jg7+f5wsG/uHCVdxttCdSARD0F01MqI+mDNbaXQluiEWtS69R8az86Sr7VFGz7 L8PZUvKih+3KyGuo49hxicSuQVlA1AAwVYZPzTSTULc9KWC8jzhcBheplYkClvmR7eUFTtAm Xref: news.gmane.org gmane.linux.lib.musl.general:13864 Archived-At: On Mon, Feb 25, 2019 at 08:50:52AM +1100, Damian McGuckin wrote: > The context of this is that I want a coding style which means I can compare > numbers without affecting the exception state. And it must have zero > overhead, and not affect the readability of the code, i.e. no function > calls. > 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)) { } This (the exception stuff) is the reason why the special cases are always front-loaded in musl. So they can be sorted out without raising spurious exceptions. The only reason the above may not be acceptable to you is that it looks like a function call. But it isn't. isnan() is a macro that doesn't always revert to a function call. > I want to know that > > x != x > > will always detect any NaN with affecting the exception status and that > comparisons like > > if (x == x) { ... } > else if (x > y) { .... } > else if (x < y) { .... } > else { x or y are NaN } > > will similarly also not modify the exception status, and in the last section > let me process how I interpret the NaNs. > 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. Honestly, though, I wonder what the big deal is. In most cases, if you see a NaN, someone probably just made an invalid operation, or chose to start another invalid operation with your function. In which case raising IE is not spurious at all. > Otherwise, avoidance of creating spurious exceptions forces you to start > working at the IEEE 754 encoding level. Or you could just use the interface provided by the C standard: if (!isnormal(x) || !isnormal(y)) { guard clause here; return; } /* definitely normal x and y from this point on. */ Hopefully you don't need to deal with subnormals... > This is counterproductive to clear > and concise programming. Such a style is riddled through a lot of the maths > routines in MUSL and the libraries that came before it. No, that's just an optimization. Musl strives to minimize the numeric error while also delivering good performance, and that means that often a lot of boundary conditions can be detected at the same time with a single comparison (e.g. you can detect "x < 0 || x > 2**limit || isinf(x)" by detecting if the exponent and sign bit together exceed a certain limit.) But nothing is stopping you from writing these conditions out entirely. Ciao, Markus