From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8920 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: for information, gcc-4.2.3 miscompiles musl math Date: Sat, 21 Nov 2015 15:15:51 -0500 Message-ID: <20151121201551.GG3818@brightrain.aerifal.cx> References: <20151121172417.GU26951@example.net> <20151121192548.GD3818@brightrain.aerifal.cx> <20151121194132.GF23362@port70.net> <20151121195144.GF3818@brightrain.aerifal.cx> <20151121200341.GH23362@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 1448136974 16401 80.91.229.3 (21 Nov 2015 20:16:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 20:16:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8933-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 21 21:16:14 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1a0EZv-0006Il-W0 for gllmg-musl@m.gmane.org; Sat, 21 Nov 2015 21:16:12 +0100 Original-Received: (qmail 32213 invoked by uid 550); 21 Nov 2015 20:16:05 -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 32190 invoked from network); 21 Nov 2015 20:16:04 -0000 Content-Disposition: inline In-Reply-To: <20151121200341.GH23362@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8920 Archived-At: On Sat, Nov 21, 2015 at 09:03:42PM +0100, Szabolcs Nagy wrote: > * Rich Felker [2015-11-21 14:51:44 -0500]: > > On Sat, Nov 21, 2015 at 08:41:32PM +0100, Szabolcs Nagy wrote: > > > * Rich Felker [2015-11-21 14:25:48 -0500]: > > > > > > > On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote: > > > > > Good to be aware of: > > > > > gcc-4.2.3 miscompiles musl math since at least 1.1.6, > > > > > tested while targeting i486, > > > > > 1.0.x seems to have been alright. > > > > > > > > > > The symptom is that sin(larger-than-2*pi) yields large values > > > > > like "sin(8.000000) = 21.709544". > > > > > Looks like the argument reduction logic has changed in a way > > > > > which is not compatible with gcc-4.2.3. > > > > > > > > Are you using configure or a hand-written config.mak? configure sets > > > > up a big hammer, -ffloat-store, when -fexcess-precision=standard is > > > > not supported (i.e. on old gcc), which hopefully suffices to make this > > > > code work, but it's possible it doesn't always do the job. > > > > > > > > > > i think this change might be it: > > > http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30 > > > > > > the new code avoids an extra store, > > > but then i rely on the evaluation > > > being in long double. > > > > > > with -ffloat-store this breaks, > > > adding extra store rounds at the > > > wrong place. > > > > Hmm, which places does it add the stores around? Could you fix it with > > an explicit conversion to double_t? That might be nice to harden > > against broken compilers without penalizing correct ones. > > > > yeah that might work > > i dont have gcc-4.2, can you try: > > diff --git a/src/math/__rem_pio2.c b/src/math/__rem_pio2.c > index a40db9f..d403f81 100644 > --- a/src/math/__rem_pio2.c > +++ b/src/math/__rem_pio2.c > @@ -118,7 +118,7 @@ int __rem_pio2(double x, double *y) > if (ix < 0x413921fb) { /* |x| ~< 2^20*(pi/2), medium size */ > medium: > /* rint(x/(pi/2)), Assume round-to-nearest. */ > - fn = x*invpio2 + toint - toint; > + fn = (double_t)x*invpio2 + toint - toint; > n = (int32_t)fn; > r = x - fn*pio2_1; > w = fn*pio2_1t; /* 1st round, good to 85 bits */ I just tested with 4.2.1 binaries from Aboriginal Linux and (1) was able to reproduce the bug, and (2) made it go away with your patch. Not only did the bogus out-of-range result go away; the new result is a bit-exact match for modern gcc. Conceptually, it seems to me that for code that explicitly uses float_t and double_t in expressions and only converts down to float or double with stores, -ffloat-store should be just as good (albeit overly pessimizing) as -fexcess-precision=standard. So IMO this looks like a really good solution, and might come in handy as hardening against mistakes in new compilers too. IIRC firm used to do this wrong and I would not be at all surprised if pcc gets it wrong. Rich