JDK-4781451 : Graph test cgt2 fails with Pascal Triangle Row Computed Incorrectly
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-11-20
  • Updated: 2015-08-25
  • Resolved: 2003-01-16
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
1.4.2 b13Fixed
Related Reports
Relates :  
JDK-4799512 - CTW assertion at loopnode.hpp, 432
Relates :  
JDK-6675699 - need comprehensive fix for unconstrained ConvI2L with narrowed type
Relates :  
JDK-4814905 - PhiNodes idealized prematurely.
Relates :  
JDK-6659207 - access violation in CompilerThread0
Description

Name: gv34239			Date: 11/19/2002


--------------------------------------
Test : jit/common/graph/cgt2
VM:  Server , d64
Mode: mixed
OS:  Solsparc

----------------------------------------
Note:

Test passed with ClientVM (comp , mixed  ,int modes)

 Failure Output:
===================
/net/vmsqe.sfbay/export/weekly/mantis/DTWS/JDK/latest/solsparc/bin/java -d64 -s
erver -DHANGINGJAVA17733 -d64 -server -Xmixed CGT -path /net/vmsqe.sfbay/export/
backup/UNIFIED-DTF/DTWS/suites/VM_FULLLOOK/testbase/src/jit/common/graph/data/ma
in.data -seed 90010647605 -thread 1 -randomLoop 4600 -staticLoop 400 -numTestCla
ss 12
##Exit status of execution step=1
##!checkExitCode

#CGT parameters
#Seed: 90010647605
#Number of Threads: 1
#Number of Random Loop iterations: 4600
#Number of Static Loop iterations: 400
#Max number of Methods in the Graph: 12
#Verbose function calls: false
#
#Pascal Tringle Row Computed Incorrectly
#Row Number 4
#Expected: 1, 1, 1, 1, 1,  Actual 1, 4, 6, 4, 1,


#########################
# To reproduce the bug:
#########################
1. cd /net/jano.sfbay/export/disk20/GammaBase/Bugs/[bug ID]
2. run rerun.sh

======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-b13 mantis-beta VERIFIED IN: mantis-beta
14-06-2004
PUBLIC COMMENTS verified on mantis b14 ###@###.### 2003-01-28
28-01-2003
SUGGESTED FIX Make TOP singleton types along loop entry edges disable the split_thru_phi() transformation for a node. ------- loopopts.cpp ------- 41c41,57 < if( t->singleton() ) { --- > bool singleton = t->singleton(); > > // A TOP singleton indicates that there are no possible values incoming > // along a particular edge. In most cases, this is OK, and the Phi will > // be eliminated later in an Ideal call. However, we can't allow this to > // happen if the singleton occurs on loop entry, as the elimination of > // the PhiNode may cause the resulting node to migrate back to a previous > // loop iteration. > if( singleton && t == Type::TOP ) { > // Is_Loop() == false does not confirm the absence of a loop (e.g., an > // irreducible loop may not be indicated by an affirmative is_Loop()); > // therefore, the only top we can split thru a phi is on a backedge of > // a loop. > singleton &= region->is_Loop() && (i != LoopNode::EntryControl); > } > > if( singleton ) { ###@###.### 2002-12-18
18-12-2002
EVALUATION ###@###.### 2002-11-20 Azeem reproduced this with a current build. ---- Seems that the problem started to occur at: 20020725215629.jrose.mantis Emailed John about this, should be easier to fix now :) ###@###.### 2002-12-05 ---- In split_thru_phi(), we attempt to push a convI2LNode with type range constraints through a phiNode at the top of a loop. The range for the conv node is 1::maxint, and the loop entry value is 0. Unioning these types gives us Type::Top. Split_thru_phi recognizes this as a profitable singleton, and performs the expected transformation. A subsequent Ideal() call on the new phi node eliminates the Phi node because the loop entry edge seems never used. This causes the use of the converted value to unwittingly propagate to the previous iteration of the loop. For example, in the method: private void verifyPascal1(int n, int[][] array) { for (int i = 0; i<=n; i++) { for (int j = 0; j<=n; j++) { if (j > 0 && j<i) { array[i][j] = array[i-1][j-1] + array[i-1][j]; } } } } our split_thru_phi() transformation causes code to be generated that makes the loop body act as if it were: array[i][j] = array[i][j-1] + array[i][j]; which is obviously wrong. ###@###.### 2002-12-18
18-12-2002