Re: [PATCH] Make musl math depend less on libgcc builtins

[Sergey Dmitrouk <sdmitrouk@accesssoftek.com>]

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