JDK-6560812 : "must set_type before use" bug in mulnode.cpp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2007-05-22
  • Updated: 2016-12-15
  • Resolved: 2014-06-02
Related Reports
Relates :  
JDK-6297035 - Automatically generated program crashes compiler on all platforms
Description
There is a bug in mulnode.cpp.  need set_type before use in mulnode.cpp. 

========= hotspot/src/share/vm/opto/mulnode.cpp#3 (text) ====
@@ -100,6 +100,7 @@
         // Convert (X+con1)*con0 into X*con0
           Node *mul = clone();    // mul = ()*con0
           mul->set_req(1,add1->in(1));  // mul = X*con0
+          phase->set_type(mul,bottom_type());
           mul = phase->transform(mul);
           Node *add2 = add1->clone();
Comments
Fixed in jdk 6 and later. 5 not supported anymore - wnf.
02-06-2014
SUGGESTED FIX --- src/share/vm/opto/mulnode.cpp *************** *** 63,71 **** op != Op_MulD ) { if( t2 == Type::TOP ) return NULL; Node *mul1 = in(1); ! if( mul1 == this ) { // Check for dead cycle ! set_req(1, phase->C->top()); ! return this; // Make it trivially dead } if( mul1->Opcode() == mul_opcode() ) { // Left input is a multiply? // Mul of a constant? --- 63,75 ---- op != Op_MulD ) { if( t2 == Type::TOP ) return NULL; Node *mul1 = in(1); ! // Check for dead loop. ! int op1 = mul1->Opcode(); ! if( phase->eqv(mul1, this) || phase->eqv(in(2), this) || ! (op1 == mul_opcode() || op1 == add_opcode()) && ! (phase->eqv(mul1->in(1), this) || phase->eqv(mul1->in(2), this) || ! phase->eqv(mul1->in(1), mul1) || phase->eqv(mul1->in(2), mul1)) ) { ! return phase->C->top(); // This code is dead. } if( mul1->Opcode() == mul_opcode() ) { // Left input is a multiply? // Mul of a constant?
17-09-2007
EVALUATION This bug could be a duplicate one of the next: 6297035, 6301887 or 6309806. All are fixed by aggressive "dead_loop" elimination fix (6297035) in 1.6 only. The 6297035 changes are big and there was bug tail.
30-05-2007
EVALUATION GVN which works during parsing doesn't set type for new nodes as Iterative GVN does. And it is fine since it will be set by transform() method after the call to Value() method. Unless they have a dead loop which could case a reference to new node's type. In this case we should find and eliminate the dead loop.
23-05-2007