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).
