[Bug c/77530] New: optimization prevents excess precision from being removed with x86/amd64 long double and rounding to 53 bits

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77530

            Bug ID: 77530
           Summary: optimization prevents excess precision from being
                    removed with x86/amd64 long double and rounding to 53
                    bits
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Under NetBSD/amd64, long double is on 80 bits but the processor is configured
to round on 53 bits (IEEE double precision) instead of 64 bits. The problem is
that when evaluating expressions at runtime, GCC seems to assume that the
rounding precision is 64 bits, yielding inconsistencies.

A test case:

#include <float.h>
#include <stdio.h>

int main (void)
{
  long double d = LDBL_MAX;
  volatile long double e = 0x8p+16380L;

  d -= 1.0;  /* no excess precision */
  printf ("d=%La e=%La\n", d, e);
  d -= e;
  printf ("d=%La\n", d);
  return 0;
}

When I compile this program with GCC 4.1.3 and the -O option under NetBSD
(gcc70.fsffrance.org), I get:

d=0xf.fffffffffffffffp+16380 e=0x8p+16380
d=0x8p+16380

The excess precision is kept in the first subtraction, but removed in the
second one.

There isn't a more recent GCC version installed on this machine, but I can
simulate this bug under Linux with the options "-std=c99 -mpc64 -O". I get the
same incorrect result with GCC 6.2.0 under Debian/unstable (amd64).