[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Sep 2014 19:14:50 +0400 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Make musl math depend less on libgcc builtins
On Thu, 11 Sep 2014, Szabolcs Nagy wrote:
> * Sergey Dmitrouk <sdmitrouk@...esssoftek.com> [2014-09-11 16:22:53 +0300]:
> > Note that I'm performing tests in QEMU. vsqrt.f64 instruction returns
> > NAN for NAN input and doesn't raise any exceptions ($fpscr register is
> > unchanged). However I get INVALID exception after printing result with
> > musl implementation of printf(), glibc doesn't raise any exceptions in
> > printf(), but I'm not sure whether it's important, probably not.
>
> nan printf should not raise invalid exceptino in musl either
>
> musl checks for nan by if(y!=y) and my guess is that this is
> incorrectly done by a signaling comparision
>
> i checked on x86_64 and both clang and gcc get comparisions
> wrong in the other direction: they use quite comparisions
> when signaling is needed, eg
>
> http://goo.gl/GsdpZA
>
> (on a correct implementation ==, != are quiet, but <,>,<=,>=
> raise invalid if any of the operands are nan, on x86_64 the
> quiet instruction is ucomis* and the signaling one is comis*
> and both gcc-4.9 and clang-3.4 seem to use ucomis* for all
> relational operations, may be there is some compiler flag to
> make them behave..)
In GCC, -mno-ieee-fp will switch ucom->com it for both == and <>.
Is that still wrong? Shouldn't there be a GCC bug filed?
Alexander
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.
