JDK-4732721 : Incorrect float value results
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0,1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-08-16
  • Updated: 2003-01-14
  • Resolved: 2002-10-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.4.1_02 02Fixed 1.4.2Fixed
Related Reports
Duplicate :  
Description

Name: rmT116609			Date: 08/16/2002


FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195] Service Pack 3

A DESCRIPTION OF THE PROBLEM :
The method which should always return the same value doesn't return the same value. The returned value depends on how many times the method was invoked and on the statements which should not affect the result.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the source code.
2. Run it.
3. You can get an incorrect float value where i >= 1499.

EXPECTED VERSUS ACTUAL BEHAVIOR :
You should always get -2.58, but after 1498 calculations you get incorrect result.

REPRODUCIBILITY :
This bug can be reproduced always.

The problem is not reproducible with -Xint or by using -server flag.

---------- BEGIN SOURCE ----------
public class Bug {
    public static void main(String[] args) {
        Bug n = new Bug();

        for(int i = 0; i < 1600; i++) {
            System.out.println(i);
            System.out.println(n.get());
        }

    }

    public float get() {
        int z0 = (int)Math.sqrt(3.3f);
        int z1 = z0 + 1;
        int inde3000 = 1+  width1*29 + z0*h1w1;
        int inde2910 = width1 + z0;
        int inde2901 = width1*29;

        float b010=0.76950276f;
        float b110=0.06863946f;
        float b101=0.025501072f;

        float c010=0.017590702f;
        float c110=0.8319669f;
        float c101=0.5642315f;

        float dd010 = -(b010 + c010*z0);
        float dd110 = -(b110 + c110*z0);
        float dd101 = -(b101 + c101*z1);
        float b_ = b110 + b101 + b010;
        float c_ =  c110 + c101 + c010;
        return -(z1 + 0.58f);
    }

    private int h1w1;
    private int width1;
}

---------- END SOURCE ----------
(Review ID: 160846) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_02 mantis FIXED IN: 1.4.1_02 mantis INTEGRATED IN: 1.4.1_02 mantis
14-06-2004

EVALUATION This bug has been present since at least 1.3.1 on x86 and probably 1.3.0. Investigated with ###@###.###. z1 is spilled during the arithmetic computations in the middle of the method. During the i2f conversion of z1 at the end of the method, z1 is not loaded into a register (since it will have to be loaded from the stack anyway). The spill slot for z1 is released and the destination for the i2f is allocated; this turns out to be a spill slot as well and is in fact the same spill slot as that for z1 since z1's spill slot has been freed. Delaying the freeing of z1's spill slot until the destination register has been allocated fixes the problem. The problematic code pattern appears to be dont_load_item(arg); item_free(arg); rlock_result(result); This is a pervasive pattern throughout the code generator and a fix needs to be systematic, preferably involving changing the code generator's infrastructure and not each usage site. ###@###.### 2002-08-16 I've implemented a fix by delaying freeing of spill slots until code generation is done for an instruction. ###@###.### 2002-09-10
16-08-2002