------- Comment #19 from dominiq at lps dot ens dot fr 2007-09-11 10:44 ------- In order to avoid a too long post, I am splitting my answer in pieces.
> PS: I should note that the bug in question is a relatively minor one: > lround(), on ppc-glibc and AIX, returns a wrong answer for the > floating-point number immediately lower than 0.5, Prec(0.5). All values > are fine, except Prec(0.5), -Prec(0.5), 4503599627370497 and > -4503599627370497. The marketing guys at Intel tried this kind of justification during the divide fiasco and got the following joke: Q&A: THE PENTIUM FDIV BUG Q: How many Pentium designers does it take to screw in a light bulb? A: 1.99904274017, but that's close enough for non-technical people. More seriously, the test fails for the above values, but this does not mean that it does not fail for other values. The most common mistake when computing nint(x) is to use int(x+0.5) without setting the rounding mode towards 0. If int(x+0.5) is used with the default round to nearest, all the values nearest(real(2**i)-0.5,-1.0) (at least) and all the odd integers between 2**51 and 2**52-1 are not rounded correctly (towards real(2**i) and even integers respectively). So before concluding that only four values give a wrong results, more tests should be performed with these known candidates for failures. This is one of my prejudice against, not the test suite itself, but its use: incorrect conclusions are drawn from incomplete test cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
