https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to jos...@codesourcery.com from comment #6) > On Thu, 14 Mar 2019, rguenther at suse dot de wrote: > > > I see. This means the different cases in the testcase in question are > > not equivalent (when excess precision is involved) and thus the > > expectation that they produce the same value is wrong which means the > > bug is INVALID? > > Yes. With, again, the question of whether glibc should be avoiding > returning with excess precision from log and other libm functions (where > at present it only tries to avoid excess range, and excess precision for > fully-determined IEEE functions such as sqrt). OK, so there's no GCC bug but forcing the glibc result to double "fixes" the issue. I'll re-file a glibc bug then. For reference, the following works as intended: #include <math.h> #include <stdio.h> int main(int argc, char **argv) { double p = 0.00053447623258905705; double inv_log_of_base = 10000.499991668185; volatile double lg = log(p); int r = lg * inv_log_of_base; printf("a: %d\n", r); double gr = log(p) * inv_log_of_base; printf("b: %g\n", gr); double g = log(p); int c = g * inv_log_of_base; printf("c: %d\n", c); return 0; }