Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Nov 2015 20:41:32 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: for information, gcc-4.2.3 miscompiles musl math

* Rich Felker <dalias@...c.org> [2015-11-21 14:25:48 -0500]:

> On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@...ey.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.

i didnt think about old toolchains
when i made that change.

this also affects rounding functions
(but i386 has asm for most of them)

i will think about it if i can change
the code so it does not break with
-ffloat-store.

> > I do not notice any problems while compiling musl with gcc-5.2, nor
> > have a compelling reason to insist on using gcc-4.2.3 (somebody else
> > might have though, gcc-4.2.3 is the last one under gpl 2).
> 
> I thought 4.2.1 was the last.
> 
> If you don't want to look into it further yourself I'll see if someone
> else interested in old toolchains can or try to get around to it
> myself. I really don't want to introduce more hacks for these broken
> compilers though. If people really still want to use them, we should
> probably just find a cheap way to fix the compiler, like patching it
> not to perform any optimizations whatsoever on floating point
> expressions.
> 
> Rich

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ