[Bug libgcj/10632] Numerical result differs from Sun JDK

[Bug libgcj/10632] Numerical result differs from Sun JDK

[jlquinn@gcc.gnu.org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632



------- Additional Comments From jlquinn@gcc.gnu.org  2003-06-01 20:23 -------
It seems like this bug should be in the java component, not libgcj.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug java/10632] Numerical result differs from Sun JDK

[debian-gcc at lists dot debian dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632


debian-gcc at lists dot debian dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |debian-gcc at lists dot
                   |                            |debian dot org


------- Additional Comments From debian-gcc at lists dot debian dot org  2003-07-06 07:30 -------
bug submitter posted this to the Debian BTS as well: http://bugs.debian.org/192035

[Bug java/10632] Numerical result differs from Sun JDK

[tromey at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632



------- Additional Comments From tromey at gcc dot gnu dot org  2003-07-06 16:22 -------
Java only requires exact FP results for
strictfp classes and methods.  So you would
have to add that to get the correct results.

Unfortunately, even if you do this, you'll
still have problems, since we don't properly
implement strictfp.

[Bug java/10632] Numerical result differs from Sun JDK

[pmoulder at mail dot csse dot monash dot edu dot au]

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