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;
}

Reply via email to