[Bug java/10632] Numerical result differs from Sun JDK
------- Additional Comments From pmoulder at mail dot csse dot monash dot edu dot au 2004-05-12 09:19 -------
(In reply to comment #5)
> Java only requires exact FP results for
> strictfp classes and methods.
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#249198
says that in absense of strictfp, implementations are allowed to use
{float,double}-extended-exponent numbers, which allow a wider _exponent_ range,
but are still required to use the normal significand width
(http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#96802).
Although not completely unambiguous, the most natural reading of sections
15.17.2, 15.4 would be that {float,double} and {float,double}-extended-exponent
are the _only_ value sets allowed, i.e. that gcj's behaviour on x86 is
non-conforming even without strictfp.
Assuming that it is desirable for gcj and other java compilers to use the target
hardware's floating point implementation (typically not strictly
ieee-conforming), I suggest filing a defect report with the Java Language
Specification.
I'm also inclined to suggest better documentation of this bug in e.g. *see
(gcj)Limitations, and possibly section "What features of the Java language
are/arn't (sic) supported" of FAQ.gcj.
Note that this bug results in more than just being wrong in the nth digit of a
calculation, but in comparisons returning the wrong result, which can result in
very different branches of a program being executed (e.g. failing assertions).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: