GCC Conversions Are Incorrect, Architecture or Otherwise

Recently I wrote about my retesting of the gcc C compiler’s string to double conversions and how it appeared that its incorrect conversions were due to an architecture-dependent bug. My examples converted incorrectly on 32-bit systems, but worked on 64-bit systems — at least most of them. I decided to dig into gcc’s source code and trace its execution, and I found the architecture dependency I was looking for. But I found more than that: due to limited precision, gcc will do incorrect conversions on any system. I’ve constructed an example to demonstrate this.

(Update 12/3/13: GCC now does correct conversions.)

Architecture Dependency AND Limited Precision

gcc’s conversion routine lives in gcc/real.c and real.h. In real.h, there’s this line:

#define SIGNIFICAND_BITS	(128 + HOST_BITS_PER_LONG)

SIGNIFICAND_BITS defines the precision used in the conversion; there are two problems wth its definition:

• Architecture Dependency. On 32-bit systems, or at least on my Intel Core i5 running the 32-bit version of Ubuntu Linux 12.04.3 with gcc 4.6.3, HOST_BITS_PER_LONG is 32; on 64-bit systems, or at least on my Intel Core i5 running the 64-bit version of Ubuntu Linux 12.04.3 with gcc 4.6.3, HOST_BITS_PER_LONG is 64. That makes SIGNIFICAND_BITS equal to 160 or 192 bits, respectively.
• Limited Precision. 160 or 192 bits is not sufficient to convert an arbitrary double-precision value.

I don’t know the rationale for choosing this constant, but I know that if I increase it and recompile gcc, it converts the example below correctly.

Example

My previous testing of gcc had not uncovered any incorrect conversions on my 64-bit system. (Such are the pitfalls of random testing — missed corner cases.) But after looking at the code, it was easy to construct an example:

5.0216813883093451685872615018317116712748411717802652598273e58

That 59 decimal digit number converts to this 196-bit binary number:

1000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001

Bit 54 (highlighted) is a 1, but we need to see through bit 196 in order to round properly (up). The correctly rounded result, as a hexadecimal floating-point constant, is 0x1.0000000000001p+195.

This is how gcc represents the number in its limited precision:

1000000000000000000000000000000000000000000000000000001111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000

It thinks bit 54 is 0, so it rounds down to 0x1p+195.

Try It Out

Here’s a C program you can use to confirm incorrect rounding on your system (it is formatted this way to fit within this article):

// gcc -o gccIncorrect gccIncorrect.c
// ./gccIncorrect
#include <stdio.h>

int main (void)
{
 char* decimal =
 "5.0216813883093451685872615018317116712748411717802652598273e58";
 double d =
 5.0216813883093451685872615018317116712748411717802652598273e58;

 printf("%s\n",decimal);
 printf(" Correct = 0x1.0000000000001p+195\n");
 printf(" gcc =     %a\n",d);
}

This is the output on my system (incorrect conversion is shaded):

5.0216813883093451685872615018317116712748411717802652598273e58
 Correct = 0x1.0000000000001p+195
 gcc =     0x1p+195

Bug Report

This is an open problem; here is the existing bug report, which I have amended.