[Bug c/17778] New: regression in evaluating long double hexadecimal constants
das at FreeBSD dot ORG
gcc-bugzilla@gcc.gnu.org
Fri Oct 1 16:18:00 GMT 2004
On FreeBSD/i386, FPU precision is set to 53 bits to avoid problems with extra
precision and double rounding for doubles. gcc understands this and evaluates
FP constants in 53-bit precision, even for long doubles. (See
ieee_extended_intel_96_round_53_format in real.c.) However, gcc occasionally
evaluates hexadecimal (and possibly decimal) floating-point constants
incorrectly starting with version 3.4:
das@VARK:~> cat bar.c
#include <stdio.h>
int main(int argc, char *argv[]) {
volatile long double d = 0x3.243f6a8885a31p0L;
printf("%La\n", d);
d = 2.0 * d / 2.0;
printf("%La\n", d);
return (0);
}
das@VARK:~> gcc33 bar.c
das@VARK:~> ./a.out
0xc.90fdaa22168cp-2
0xc.90fdaa22168cp-2
das@VARK:~> gcc bar.c
das@VARK:~> ./a.out
0xc.90fdaa22168c4p-2
0xc.90fdaa22168cp-2
das@VARK:~> gcc --version
gcc (GCC) 3.4.2 [FreeBSD] 20040728
das@VARK:~> gcc33 --version
gcc33 (GCC) 3.3.5 20040630 (prerelease) [FreeBSD]
In the tests I've tried, the symptoms were always setting the 57th mantissa bit,
even when the number would not have that bit set when rounded to 57 bits. Given
the position of the incorrect bit, I suspect that the bug is due to either a
mistake in the way rounding is handled, or, more likely, an endianness mistake
in the handling of the sign bit that doesn't show up in the 96-bit format since
the 97th bit is ignored.
--
Summary: regression in evaluating long double hexadecimal
constants
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: das at FreeBSD dot ORG
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-freebsd6.0
GCC host triplet: i386-unknown-freebsd6.0
GCC target triplet: i386-unknown-freebsd6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778
More information about the Gcc-bugs
mailing list