[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140911114207.GA5041@zx-spectrum>
Date: Thu, 11 Sep 2014 14:42:07 +0300
From: Sergey Dmitrouk <sdmitrouk@...esssoftek.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] Make musl math depend less on libgcc builtins
Hi,
> floating-point arithmetics is not done by the compiler runtime
I do understand that, but got lost after observing different results
produced by same code compiled with different compilers.
> misoptimize code that depends on non-default fenv or accesses fenv
>
> 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.
> i dont see any gcc builtins used, we rely on c99 fenv semantics
I meant builtins inserted by compiler, which I saw while debugging
tests. Now I think that was soft floating point, although it's not what
I want, hard float should be used instead. I might have relied to much
on compiler defaults.
> FE_* macros may be undefined for a target so their use always
> have to be ifdefed
I read this somewhere, but wasn't sure that it's target specific.
> so should we raise the invalid flag manually or rely on that
> the compiler will use fpu intructions which do it for us?
>
> that said, i'm open to changes in the current policy since no
> compiler supports FENV_ACCESS correctly and there does not seem
> to be much willingness to fix this
>
> - reorderings around fesetround, fetestexcept, feclearexcept
> are harder to fix, but we only use those in a few places so
> volatile hacks may not be terrible
>
> - for exception raising if we can reliably identify the places
> where the compiler miscompiles/constant folds the code then we
> can fix those with explicit feraise (or volatile hacks) if it
> does not have too much impact otherwise
Fixing it in musl won't help other applications compiled with Clang, so
I'd prefer to fix such issues in the compiler.
> 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.
> applied and did the same for jnf, yn, ynf
Thanks, I didn't notice it in other tests.
Thanks for your verbose comments. I'll need to figure out why exceptions
are not raised in some cases, but now I understand that I went into wrong
direction blaming musl on this.
Regards,
Sergey
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.
