From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6141 Path: news.gmane.org!not-for-mail From: Sergey Dmitrouk Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Make musl math depend less on libgcc builtins Date: Thu, 11 Sep 2014 14:42:07 +0300 Message-ID: <20140911114207.GA5041@zx-spectrum> References: <20140911073532.GA3179@zx-spectrum> <20140911094705.GF21835@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: ger.gmane.org 1410435751 5721 80.91.229.3 (11 Sep 2014 11:42:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 11:42:31 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-6154-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 13:42:23 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS2la-0005Fk-N0 for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 13:42:22 +0200 Original-Received: (qmail 3426 invoked by uid 550); 11 Sep 2014 11:42:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3418 invoked from network); 11 Sep 2014 11:42:21 -0000 Content-Disposition: inline In-Reply-To: <20140911094705.GF21835@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:6141 Archived-At: 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