[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260814095116.GD3542221@port70.net>
Date: Fri, 14 Aug 2026 11:51:16 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Sergey Davidoff <shnatsel@...il.com>, musl@...ts.openwall.com
Subject: Re: Bug in fmaf: subnormals are rounded incorrectly
* Szabolcs Nagy <nsz@...t70.net> [2026-08-13 06:38:56 +0200]:
> e.g. there is still a known bug in fmaf: on architectures
> where underflow is raised before rounding (arm, ppc) we can
> fail to raise it if the rounded result is not subnormal:
>
> fmaf(-0x1p-100f,0x1p-100f,0x1p-126f)
>
> this can be fixed with a few extra checks, i did that for fma,
> but piling up such cornercase cheks is what leads to subtle
> bugs (target specifc, hard to optimize, etc).
...
> i cleaned up fmaf now, but not with int code like in fma, so
> issues like the uflow bug would be hard to fix. this is patch 2.
i think this can be fixed and fmaf simplified by using
given any real |x| in 0x1p-149 .. 0x1p128
y = (float)x
is same as
r = (double)x
t = x - r
u = bits(r)
if (t!=0 && u%4==0)
r = asdouble(sign(r)==sign(t) ? u+1 : u-1)
y = (float)r
in all rounding modes, with same fenv.
we can filter out the easy cases (e.g non-halfway normals)
and only do this for a small subset containing the tricky
cases, but we don't need to check the rounding mode nor
compute halfway cases for subnormals or the exact uflow
boundary, just arrange the last cast to be inexact when x
is not a float by nudging it to the right direction.
for given float a,b,c computing exact r + t == a*b+c is
easy, this looks simpler to me than emulating round to odd.
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.
