Comments on: Incorrectly Rounded Conversions in GCC and GLIBC http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/ Binary Numbers, Binary Code, and Binary Logic Mon, 30 Jan 2012 01:37:52 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Neil http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4881 Neil Sun, 27 Feb 2011 04:32:42 +0000 http://www.exploringbinary.com/?p=285#comment-4881 Heh, just found this article. Happy to see clang gets it right; I contributed their decimal->binary code :-) I submitted the GCC bug 6 years ago; shame there's little progress. Heh, just found this article. Happy to see clang gets it right; I contributed their decimal->binary code :-)

I submitted the GCC bug 6 years ago; shame there’s little progress.

]]> By: Rick Regan http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4805 Rick Regan Wed, 09 Feb 2011 18:09:05 +0000 http://www.exploringbinary.com/?p=285#comment-4805 @Bob, Thanks for the report. Your results match the results of an AMD64 user on reddit. What system or you on? @Bob,

Thanks for the report. Your results match the results of an AMD64 user on reddit. What system or you on?

]]> By: bob nelson http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4803 bob nelson Wed, 09 Feb 2011 17:29:43 +0000 http://www.exploringbinary.com/?p=285#comment-4803 gcc 4.4.5: 0.500000000000000166533453693773481063544750213623046875 Correct = 0x1.0000000000002p-1 gcc = 0x1.0000000000002p-1 strtod = 0x1.0000000000001p-1 3.518437208883201171875e13 Correct = 0x1.0000000000002p+45 gcc = 0x1.0000000000002p+45 strtod = 0x1.0000000000001p+45 62.5364939768271845828 Correct = 0x1.f44abd5aa7ca4p+5 gcc = 0x1.f44abd5aa7ca4p+5 strtod = 0x1.f44abd5aa7ca3p+5 8.10109172351e-10 Correct = 0x1.bd5cbaef0fd0cp-31 gcc = 0x1.bd5cbaef0fd0cp-31 strtod = 0x1.bd5cbaef0fd0cp-31 1.50000000000000011102230246251565404236316680908203125 Correct = 0x1.8p+0 gcc = 0x1.8p+0 strtod = 0x1.8p+0 9007199254740991.4999999999999999999999999999999995 Correct = 0x1.fffffffffffffp+52 gcc = 0x1.fffffffffffffp+52 strtod = 0x1.fffffffffffffp+52 gcc 4.4.5:

0.500000000000000166533453693773481063544750213623046875
Correct = 0×1.0000000000002p-1
gcc = 0×1.0000000000002p-1
strtod = 0×1.0000000000001p-1

3.518437208883201171875e13
Correct = 0×1.0000000000002p+45
gcc = 0×1.0000000000002p+45
strtod = 0×1.0000000000001p+45

62.5364939768271845828
Correct = 0×1.f44abd5aa7ca4p+5
gcc = 0×1.f44abd5aa7ca4p+5
strtod = 0×1.f44abd5aa7ca3p+5

8.10109172351e-10
Correct = 0×1.bd5cbaef0fd0cp-31
gcc = 0×1.bd5cbaef0fd0cp-31
strtod = 0×1.bd5cbaef0fd0cp-31

1.50000000000000011102230246251565404236316680908203125
Correct = 0×1.8p+0
gcc = 0×1.8p+0
strtod = 0×1.8p+0

9007199254740991.4999999999999999999999999999999995
Correct = 0×1.fffffffffffffp+52
gcc = 0×1.fffffffffffffp+52
strtod = 0×1.fffffffffffffp+52

]]> By: Michel Hack http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4471 Michel Hack Mon, 03 Jan 2011 22:42:39 +0000 http://www.exploringbinary.com/?p=285#comment-4471 My mistake! 754-1985 does not require correct rounding for 22 digits. I misremembered the 22-digit size of the #3479 example, probably because I've also investigated a number of 17-digit (and even 16-digit) failures on non-Linux systems. It is still a glibc bug however, because the comments, and the use of gmp under the covers, clearly suggest that the intention was to perform correct rounding... Given that glibc uses gmp to convert at least 20 digits, I suspect that it does not have bugs within the IEEE 754-1985 correct-rounding range. (For the record, that range is numbers representable as M*10**N with integers M and N such that |M| < 1e17 and |N| < 28.) Of course, by now there is IEEE 754-2008 to contend with! If binary64 is the widest supported FP format, then 20 correctly-rounded digits would be conforming, provided longer digit strings are first rounded in decimal to 20 digits, which I suspect is NOT being done. (That's understandable, because that particular requirement was only formulated in late 2006 if I remember correctly.) So perhaps I should torture glibc's strtod() a bit more on post-2008 versions... Michel. My mistake! 754-1985 does not require correct rounding for 22 digits.
I misremembered the 22-digit size of the #3479 example, probably
because I’ve also investigated a number of 17-digit (and even 16-digit)
failures on non-Linux systems.

It is still a glibc bug however, because the comments, and the use of
gmp under the covers, clearly suggest that the intention was to perform
correct rounding…

Given that glibc uses gmp to convert at least 20 digits, I suspect that it
does not have bugs within the IEEE 754-1985 correct-rounding range.
(For the record, that range is numbers representable as M*10**N with
integers M and N such that |M| < 1e17 and |N| < 28.)

Of course, by now there is IEEE 754-2008 to contend with! If binary64
is the widest supported FP format, then 20 correctly-rounded digits would
be conforming, provided longer digit strings are first rounded in decimal
to 20 digits, which I suspect is NOT being done. (That's understandable,
because that particular requirement was only formulated in late 2006 if
I remember correctly.)

So perhaps I should torture glibc's strtod() a bit more on post-2008
versions…

Michel.

]]> By: Rick Regan http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4470 Rick Regan Mon, 03 Jan 2011 16:38:04 +0000 http://www.exploringbinary.com/?p=285#comment-4470 Michel, The example in Bugzilla #3479, 3.518437208883201171875E+013, is 22 digits. Is that required to be correctly rounded? Michel,

The example in Bugzilla #3479, 3.518437208883201171875E+013, is 22 digits. Is that required to be correctly rounded?

]]> By: Michel Hack http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4469 Michel Hack Sun, 02 Jan 2011 17:13:44 +0000 http://www.exploringbinary.com/?p=285#comment-4469 This reply is a bit late, but I was not following this discussion, and only got here because of your reply on stds-754 (Re: Conflicts between C standard and 754-2008). My bugzilla #3479 violates 754-1985 because it involves fewer than 17 digits and has a middling exponent, within the range where correct rounding is required. I'm a bit annoyed that there has been no progress in four years, even though the fix should be pretty trivial (don't take the invalid shortcut) -- but I'm not sufficiently plugged in to the glibc maintenance community to provide my own bug fix. Michel This reply is a bit late, but I was not following this discussion, and only got
here because of your reply on stds-754 (Re: Conflicts between C standard
and 754-2008).

My bugzilla #3479 violates 754-1985 because it involves fewer than 17
digits and has a middling exponent, within the range where correct rounding
is required.

I’m a bit annoyed that there has been no progress in four years, even though
the fix should be pretty trivial (don’t take the invalid shortcut) — but I’m not
sufficiently plugged in to the glibc maintenance community to provide my own
bug fix.

Michel

]]> By: Rick Regan http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4354 Rick Regan Tue, 08 Jun 2010 13:06:58 +0000 http://www.exploringbinary.com/?p=285#comment-4354 Michel, My Example 2 is from your bug report (it's a halfway case that should round up, not down). Can you elaborate on why it "violates 754-1985"? Thanks. (BTW, it's 20 digits that the shortcut uses.) Michel,

My Example 2 is from your bug report (it’s a halfway case that should round up, not down). Can you elaborate on why it “violates 754-1985″? Thanks.

(BTW, it’s 20 digits that the shortcut uses.)

]]> By: Michel Hack http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4353 Michel Hack Sun, 06 Jun 2010 18:06:46 +0000 http://www.exploringbinary.com/?p=285#comment-4353 (1) C99 and IEEE 754-1985 are somewhat lax on conversion requirements, but IEEE 754-2008 requires correct rounding across the entire exponent range and for at least 20 digits in the case of Binary64. (2) The bug I reported for glibc several years ago actually violates 754-1985. (3) The code in glibc is perfectly capable of doing the correct conversion. The problem is an ill-advised shortcut that claims n digits (30? I don't remember now) are sufficient, when in fact the threshold is much larger (it depends on the exponent and may be as large as 752 bits). Michel. (1) C99 and IEEE 754-1985 are somewhat lax on conversion requirements, but IEEE 754-2008 requires correct rounding across the entire exponent range and for at least 20 digits in the case of Binary64.
(2) The bug I reported for glibc several years ago actually violates 754-1985.
(3) The code in glibc is perfectly capable of doing the correct conversion. The problem is an ill-advised shortcut that claims n digits (30? I don’t remember now) are sufficient, when in fact the threshold is much larger (it depends on the exponent and may be as large as 752 bits).

Michel.

]]> By: eddie http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4352 eddie Sat, 05 Jun 2010 12:14:39 +0000 http://www.exploringbinary.com/?p=285#comment-4352 It's stock ubuntu 10.4 with the default clang in ubuntu multiverse: clang-2.7-0ubuntu1 It’s stock ubuntu 10.4 with the default clang in ubuntu multiverse: clang-2.7-0ubuntu1

]]> By: Rick Regan http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4351 Rick Regan Sat, 05 Jun 2010 01:59:06 +0000 http://www.exploringbinary.com/?p=285#comment-4351 eddie, What's really interesting is that your results are different than the five other sets of results I have (my results above and the 4 sets of results reported on <a title="See results on Reddit" href="http://www.reddit.com/r/programming/comments/cb8qv/incorrectly_rounded_conversions_in_gcc_and_glibc/" rel="nofollow">reddit</a>). Thanks for the data. eddie,

What’s really interesting is that your results are different than the five other sets of results I have (my results above and the 4 sets of results reported on reddit).

Thanks for the data.

]]> By: eddie http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4350 eddie Sat, 05 Jun 2010 00:57:47 +0000 http://www.exploringbinary.com/?p=285#comment-4350 clang 1.1.27 does the rounding right (eglibc still fails, that was expected), but I'm worried because it doesn't mimic gcc behaviour when using gcc_conversion, and that will lead to obscure bugs to someone. Note: The source program was not modified in any way, gcc in the program refers to clang instead. esanchma@esanchma-virtualized-linux:~/Escritorio$ clang -o examples-clang examples.c esanchma@esanchma-virtualized-linux:~/Escritorio$ ./examples-clang 0.500000000000000166533453693773481063544750213623046875 Correct = 0x1.0000000000002p-1 gcc = 0x1.0000000000002p-1 strtod = 0x1.0000000000001p-1 3.518437208883201171875e13 Correct = 0x1.0000000000002p+45 gcc = 0x1.0000000000002p+45 strtod = 0x1.0000000000001p+45 62.5364939768271845828 Correct = 0x1.f44abd5aa7ca4p+5 gcc = 0x1.f44abd5aa7ca4p+5 strtod = 0x1.f44abd5aa7ca3p+5 8.10109172351e-10 Correct = 0x1.bd5cbaef0fd0cp-31 gcc = 0x1.bd5cbaef0fd0cp-31 strtod = 0x1.bd5cbaef0fd0dp-31 1.50000000000000011102230246251565404236316680908203125 Correct = 0x1.8p+0 gcc = 0x1.8p+0 strtod = 0x1.8p+0 9007199254740991.4999999999999999999999999999999995 Correct = 0x1.fffffffffffffp+52 gcc = 0x1.fffffffffffffp+52 strtod = 0x1.fffffffffffffp+52 esanchma@esanchma-virtualized-linux:~/Escritorio$ clang --version clang version 1.1 (branches/release_27) Target: i386-pc-linux-gnu Thread model: posix clang 1.1.27 does the rounding right (eglibc still fails, that was expected), but I’m worried because it doesn’t mimic gcc behaviour when using gcc_conversion, and that will lead to obscure bugs to someone.

Note: The source program was not modified in any way, gcc in the program refers to clang instead.

esanchma@esanchma-virtualized-linux:~/Escritorio$ clang -o examples-clang examples.c
esanchma@esanchma-virtualized-linux:~/Escritorio$ ./examples-clang
0.500000000000000166533453693773481063544750213623046875
Correct = 0×1.0000000000002p-1
gcc = 0×1.0000000000002p-1
strtod = 0×1.0000000000001p-1

3.518437208883201171875e13
Correct = 0×1.0000000000002p+45
gcc = 0×1.0000000000002p+45
strtod = 0×1.0000000000001p+45

62.5364939768271845828
Correct = 0×1.f44abd5aa7ca4p+5
gcc = 0×1.f44abd5aa7ca4p+5
strtod = 0×1.f44abd5aa7ca3p+5

8.10109172351e-10
Correct = 0×1.bd5cbaef0fd0cp-31
gcc = 0×1.bd5cbaef0fd0cp-31
strtod = 0×1.bd5cbaef0fd0dp-31

1.50000000000000011102230246251565404236316680908203125
Correct = 0×1.8p+0
gcc = 0×1.8p+0
strtod = 0×1.8p+0

9007199254740991.4999999999999999999999999999999995
Correct = 0×1.fffffffffffffp+52
gcc = 0×1.fffffffffffffp+52
strtod = 0×1.fffffffffffffp+52

esanchma@esanchma-virtualized-linux:~/Escritorio$ clang –version
clang version 1.1 (branches/release_27)
Target: i386-pc-linux-gnu
Thread model: posix

]]> By: Rick Regan http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/comment-page-1/#comment-4349 Rick Regan Fri, 04 Jun 2010 21:06:10 +0000 http://www.exploringbinary.com/?p=285#comment-4349 Hi lacos, Yes, I am familiar with that C99 text (in fact, it popped up recently on stackoverflow.com). The bottom line is you're right -- it's not a bug. I don't disagree, but that doesn't mean correct rounding shouldn't be the goal. After all, there are open "bug" reports in gcc and glibc, which means they think it worthy of consideration. And, there is open source code available that does correct rounding. BTW, the terms "correct" and "incorrect" might be misleading, but they're not my terms. A correctly rounded conversion means the closer of two binary floating-point numbers is chosen (I'm assuming the default -- "round to nearest even" -- but other rounding modes can be applied.) Thanks for the comment. Hi lacos,

Yes, I am familiar with that C99 text (in fact, it popped up recently on stackoverflow.com). The bottom line is you’re right — it’s not a bug. I don’t disagree, but that doesn’t mean correct rounding shouldn’t be the goal. After all, there are open “bug” reports in gcc and glibc, which means they think it worthy of consideration. And, there is open source code available that does correct rounding.

BTW, the terms “correct” and “incorrect” might be misleading, but they’re not my terms. A correctly rounded conversion means the closer of two binary floating-point numbers is chosen (I’m assuming the default — “round to nearest even” — but other rounding modes can be applied.)

Thanks for the comment.

]]>