[PATCH] various fixes detected with -Wdouble-promotion
Paul Zimmermann
Paul.Zimmermann@inria.fr
Mon Oct 13 11:22:47 GMT 2025
Hi Paul,
> > as changes like this:
> >
> > - p6 = p[6] + y * -0xf.ff6b8p-12;
> > + p6 = p[6] + y * -0xf.ff6b8p-12f;
> >
> > in the patch show, Glibc would be better off being clean w.r.t
> > -Wdouble-promotion.
>
> That change is questionable, as it appears that the error induced by
> sticking to single precision likely outweighs the error induced by
> double-rounding. If it's really the intent to increase the error (or if
> there's some reason the error is not increased), this change (and
> similar changes) should be accompanied by commentary stating why the
> code sticks to single precision even though double precision would
> apparently yield less error.
I did some exhaustive check for all values that enter this part of the
code, i.e., 0x1.bdb4c2p+2 <= x <= 0x1.c27a8cp+2 where x is a float (index = 1).
For rounding to nearest, I get no difference between the value returned
by y1f_near_root() with/without the f suffix in -0xf.ff6b8p-12.
But you are right to ask the question. If j1f() would be correctly rounded,
it might be indeed that this change would break correct rounding. But for now
we only target an error <= 9 ulps for j1f.
> Sorry if my earlier message seemed offputting. My intent was only to
> focus on maintainability (and I guess now on correctness), instead of
> focusing on the secondary goal of pacifying false alarms from the compiler.
no worry, I saw no offense. It is good that we can have different opinions on
this list. Personally I wish I had known -Wdouble-promotion before, since this
would have saved several times me some time to find why my code was so slow.
Paul Z.
More information about the Libc-alpha
mailing list