[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMKF1sowuk7rKkWMrxZPajC5HnCuaR7g1mtNcnGC5WHPbJYjHw@mail.gmail.com>
Date: Tue, 11 Mar 2025 10:59:52 -0700
From: Khem Raj <raj.khem@...il.com>
To: musl@...ts.openwall.com
Cc: Victor Stinner <vstinner@...hon.org>
Subject: Re: Bug in fma(): should return negative zero
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
> 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.
