This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/33271] nint_2.f90 abort compiled with -O0



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]