[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250311170923.GC1827@brightrain.aerifal.cx>
Date: Tue, 11 Mar 2025 13:09:23 -0400
From: Rich Felker <dalias@...c.org>
To: Victor Stinner <vstinner@...hon.org>
Cc: musl@...ts.openwall.com
Subject: Re: Bug in fma(): should return negative zero
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...
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.
