[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Sep 2014 14:26:51 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Make musl math depend less on libgcc builtins
* Sergey Dmitrouk <sdmitrouk@...esssoftek.com> [2014-09-11 14:42:07 +0300]:
> > gcc just happens to work usually with -frounding-math, clang makes no attempt
> > to undo its optimizations with any compiler flags (except -O0 which is not
> > what most ppl want) like constant folding 1/0.0 into INFINITY
>
> I though that lack of -frounding-math flag support in Clang might be the
> reason of errors, but I didn't realize optimizations can harm floating
> point operations.
>
note that constant folding 1/0.0 is valid if FENV_ACCESS is OFF
(it is off by default), however if FENV_ACCESS ON is not supported
then ON should be always assumed and then constant folding is not ok
(this is where both gcc and clang are wrong when -std=c99 is specified
however they don't claim complete annex f support so it is hard to
argue this point)
http://port70.net/~nsz/c/c11/n1570.html#F.8.4p1
> > this should not be needed, overflowing float to int conversion
> > raises the invalid flag implicitly, if it does not then clang/llvm
> > generates wrong code for the conversion
>
> Well, it doesn't, will need to figure out why. Because of strange
> results I interpreted the whole thing in a wrong way, as if exceptions
> were semi automatic and libc implementation had to raise some exceptions
> manually in places where things defined by C standard differ from what
> IEEE754 implementation gives us. You helpful comments sorted that out
> for me.
>
> > > diff --git a/src/math/sqrtl.c b/src/math/sqrtl.c
> > > index 83a8f80..0872e15 100644
> > > --- a/src/math/sqrtl.c
> > > +++ b/src/math/sqrtl.c
> > > @@ -3,5 +3,5 @@
> > > long double sqrtl(long double x)
> > > {
> > > /* FIXME: implement in C, this is for LDBL_MANT_DIG == 64 only */
> > > - return sqrt(x);
> > > + return isnan(x) ? 0.0l/0.0l : sqrt(x);
> > > }
> >
> > why?
>
> sqrt(NAN) raises INVALID exception, 0.0l/0.0l doesn't for me (well,
> optimization must've prevented that).
>
> > nan is also sticky (passes through any arithmetics and
> > comes out as nan) so if sqrt(NAN) is not nan now then
> > that's a bug somewhere
>
> sqrt(NAN) == NAN, I just wanted to silent the exception.
now that you mention i got reports of spurious invalid
exceptions for nan inputs on arm, but i don't have hardfloat
arm toolchain
if you have further info on this that would be helpful
(from the arm docs it seems to me that vfp sqrt should work
according to ieee so either that is wrong or our fenv
exception test is not ok on arm)
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.
