[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250311182225.GE1827@brightrain.aerifal.cx>
Date: Tue, 11 Mar 2025 14:22:25 -0400
From: Rich Felker <dalias@...c.org>
To: Khem Raj <raj.khem@...il.com>
Cc: musl@...ts.openwall.com, Victor Stinner <vstinner@...hon.org>
Subject: Re: Bug in fma(): should return negative zero
On Tue, Mar 11, 2025 at 10:59:52AM -0700, Khem Raj wrote:
> On Tue, Mar 11, 2025 at 10:35 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Tue, Mar 11, 2025 at 01:09:23PM -0400, Rich Felker wrote:
> > > On Tue, Mar 11, 2025 at 05:19:26PM +0100, Victor Stinner wrote:
> > > > Hi,
> > > >
> > > > On Tue, Mar 11, 2025 at 2:25 PM Rich Felker <dalias@...c.org> wrote:
> > > > > What archs have you tested it on?
> > > >
> > > > I tested on x86-64.
> > > >
> > > > > It doesn't happen for me and the general C code looks like it handles
> > > > > this case correctly,
> > > >
> > > > Oh. I can reproduce the issue with my C example on:
> > > >
> > > > * Fedora 41: musl 1.2.5-1, musl-gcc version "gcc (GCC) 14.2.1"
> > > > * Alpine Linux v3.21: musl-1.2.5-r9, gcc version 14.2.0.
> > > >
> > > > Example on Fedora:
> > > > ---
> > > > $ musl-gcc x.c -o x && ./x
> > > > fma(+1e-300, -1e-300, +0) = +0
> > > > ---
> > > >
> > > > The result is wrong (+0), it must be "-0": fma(x, y, z) = (+1e-300) *
> > > > (-1e-300) + (+0) = -0.
> > >
> > > Indeed, the correct result is -0 and +0 is wrong. But there is no bug
> > > in musl. The bug is in the version of gcc used to compile musl. Using
> > > gcc 13.2.1 on Alpine 3.20 and building musl myself, fma correctly
> > > returns -0. But the musl binary shipped with Alpine 3.20 has been
> > > miscompiled so that the "return x*y;" on line 56 incorrectly just
> > > branches to line 53's "return x*y+z;".
> > >
> > > I'm not sure what the buggy version of gcc is, but I would guess it's
> > > a new regression in gcc 14. So I guess we need to track this down and
> > > report it. My guess is that someone wrongly thought they could infer
> > > from the branches on the bit representation of the float that it's
> > > zero, and thereby "of course adding zero is a no-op" (no! no! NO!) so
> > > they folded the two code paths to the same thing...
> >
> > Ah, no, I should have checked. This is a bug in musl that was fixed by
> > nsz last year in git, but the fix hasn't made it into any release.
> >
>
> In yocto we use the tip of the trunk and I was not able to reproduce as well.
> This is the commit which is helping I think.
>
> https://git.musl-libc.org/cgit/musl/commit/?id=9683bd62414604d3bd56cf6bd7be8f54aa31e7d3
Yep, that's the one and it fixes exactly this bug.
Rich
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.
