|
|
Message-ID: <20260816233216.GF3542221@port70.net> Date: Mon, 17 Aug 2026 01:32:16 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com, Sergey Davidoff <shnatsel@...il.com> Subject: Re: [PATCH v2] math: fmaf rewrite and bug fixes * Rich Felker <dalias@...c.org> [2026-08-16 18:23:36 -0400]: > On Sun, Aug 16, 2026 at 10:35:44PM +0200, Szabolcs Nagy wrote: > > i no longer think a separate bugfix patch is useful. > > Unless you think it's wrong or incomplete in fixing the wrong-value > bug (wrong flags is far less of an issue), I'd like to go ahead and > apply the direct fix first. It's friendlier to bugfix-only backporting > which users may want to do for an old version they're using, and > documents the bug clearly and allows verifying any differences with > bisect. the idea was that users can just backport the rewrite. minimal fix is less likely to cause regression and conflicts. but fmaf is very tightly specified so unless new bugs are introduced at least the rewrite will not be observable to user code and i don't expect conflicting fmaf.c changes. > > + /* correct except for inf, nan and some (r&1)==1 cases. > > + r+t == x*y+z exactly in nearest rounding mode and in > > + other modes t!=0 and t<0 checks are not affected. > > + if t==0 then inexact is not signaled. */ > > + int s = u.i >> 63; > > + double t = s == (xy < z) ? xy - u.r + z : z - u.r + xy; > > + if (t) > > + /* adjust r toward r+t */ > > + u.i += s == (t < 0) ? 1 : -1; > > } > > Looks good. Small style nit: *'s on the continuation lines of comment > to be easily distinguishable from code. > > Does this all sound ok? yes i can do the minimal fix first and do the * prefix in the new code
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.