Bug 10632 - Numerical result differs from Sun JDK -- strictfp not supported
Summary: Numerical result differs from Sun JDK -- strictfp not supported
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.2.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 24454 (view as bug list)
Depends on:
Blocks: 24454
  Show dependency treegraph
 
Reported: 2003-05-05 21:36 UTC by jens.mueller
Modified: 2007-05-30 13:36 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-01-26 05:26:55


Attachments
PiApproximationRecursive.java (700 bytes, text/plain)
2003-05-21 15:17 UTC, jens.mueller
Details
short test case showing difference from sun jdk (412 bytes, text/plain)
2004-05-12 08:25 UTC, Peter Moulder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jens.mueller 2003-05-05 21:36:01 UTC
Please look at the file.

I compiled it with java from Sun (Blackdown) JDK 1.4.1, and ran it
with java from the same package:

jens@debian:~/studium/semester2/info2/ue1java$ java PiApproximationRecursive 20000
3.1415426535898248
Approximierter Wert für pi: 3.1415426535898248


I also compiled it with
gcj --main=PiApproximationRecursive PiApproximationRecursive.java

I got this result:

jens@debian:~/studium/semester2/info2/ue1java$ ./a.out 20000
3.1415426535898208
Approximierter Wert für pi: 3.1415426535898208


I think that the Java Language Standard clearly specifies the order in
which expressions are evaluated. The result of a single floating point
operation is specified in the respective IEEE standards.

So either gcj's or JDK's behavior is broken here ...

I suppose the former.


P.S.: Compiling to a .class file with gcj-wrapper-3.2 and
running with gij (3.0, in that case) gives yet another result ...


-- System Information
Debian Release: testing/unstable
Kernel Version: Linux debian 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686 unknown unknown GNU/Linux

Versions of the packages gcj-3.2 depends on:
ii  gcc-3.2        3.2.3-0pre9    The GNU C compiler
ii  gcc-3.2-base   3.2.3-0pre9    The GNU Compiler Collection (base package)
ii  java-common    0.19           Base of all Java packages
ii  libc6          2.3.1-16       GNU C Library: Shared libraries and Timezone
ii  libgcj3        3.2.3-0pre9    Java runtime library for use with gcj
ii  libgcj3-dev    3.2.3-0pre9    Java development headers and static library 
ii  zlib1g         1.1.4-11       compression library - runtime

Release:
unknown
Comment 1 Dara Hazeghi 2003-05-12 15:56:39 UTC
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libgcj/10632: Numerical result differs from Sun JDK
Date: Mon, 12 May 2003 15:56:39 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=10632
 
 Hello,
 
 I can replicate the results in this report on gcc 3.2, 3.3 branch and  
 mainline (20030511).
 
 Dara
Comment 2 Andrew Pinski 2003-05-28 03:39:35 UTC
See Dara's comment and I can confirm it on the mainline (20030527):
tin:~/src/gnu/gcctest>gcj -O3 --main=PiApproximationRecursive PiApproximationRecursi
ve.java
tin:~/src/gnu/gcctest>./a.out 20000
3.141542653589829
Approximierter Wert f<caron>´´?r pi: 3.141542653589829
tin:~/src/gnu/gcctest>gcj -O3 --main=PiApproximationRecursive PiApproximationRecursi
ve.java -ffloat-store
tin:~/src/gnu/gcctest>./a.out 20000
3.1415426535898208
Approximierter Wert f<caron>´´?r pi: 3.1415426535898208
tin:~/src/gnu/gcctest>java PiApproximationRecursive 20000
3.1415426535898248
Approximierter Wert f¸r pi: 3.1415426535898248
tin:~/src/gnu/gcctest>gcj -O3 --main=PiApproximationRecursive PiApproximationRecursi
ve.java -ffloat-store -ffast-math
tin:~/src/gnu/gcctest>./a.out 20000
3.1415426535898208
Approximierter Wert f<caron>´´?r pi: 3.1415426535898208
tin:~/src/gnu/gcctest>gcj -O3 --main=PiApproximationRecursive PiApproximationRecursi
ve.java  -ffast-math
tin:~/src/gnu/gcctest>./a.out 20000
3.141542653589829
Approximierter Wert f<caron>´´?r pi: 3.141542653589829
tin:~/src/gnu/gcctest>gij PiApproximationRecursive 20000
3.1415426535898243
Approximierter Wert f<caron>´´?r pi: 3.1415426535898243
tin:~/src/gnu/gcctest>
Comment 3 Jerry Quinn 2003-06-01 20:23:34 UTC
It seems like this bug should be in the java component, not libgcj.
Comment 4 Debian GCC Maintainers 2003-07-06 07:30:00 UTC
bug submitter posted this to the Debian BTS as well: http://bugs.debian.org/192035
Comment 5 Tom Tromey 2003-07-06 16:22:09 UTC
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.
Comment 6 Peter Moulder 2004-05-12 08:25:22 UTC
Created attachment 6263 [details]
short test case showing difference from sun jdk

The attached short program suggests that the problem is in use of fp registers
(64-bit significand on x86 instead of 53 bits) for intermediate results.
Comment 7 Peter Moulder 2004-05-12 09:19:44 UTC
(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).
Comment 8 Andrew Haley 2007-05-30 13:36:32 UTC
*** Bug 24454 has been marked as a duplicate of this bug. ***