This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR tree-optimization/22230


Hi,

This is a wrong-code bug caused by VRP.

The bug is that the 4 cross operations are not computed properly.  In 
extract_range_from_binary_expr we compute them as follows: 
 
      /* Compute the 4 cross operations.  */ 
      val[0] = vrp_int_const_binop (code, vr0.min, vr1.min); 
 
      val[1] = (vr1.max != vr1.min) 
               ? vrp_int_const_binop (code, vr0.min, vr1.max) 
               : NULL_TREE; 
 
      val[2] = (vr0.max != vr0.min) 
               ? vrp_int_const_binop (code, vr0.max, vr1.min) 
               : NULL_TREE; 
 
      val[3] = (vr0.min != vr1.min && vr0.max != vr1.max) 
               ? vrp_int_const_binop (code, vr0.max, vr1.max) 
               : NULL_TREE; 
 
We compute this for "i*i" so vr0.min == vr1.min and vr0.max == vr1.max,  
because vr0 and vr1 are the same (both are the range for i, which is [0,4] 
at this point). 
 
We end up with: 
val[0] = <integer_cst type <integer_type "long int"> constant invariant 0> 
val[1] = <integer_cst type <integer_type "long int"> constant invariant 0> 
val[2] = <integer_cst type <integer_type "long int"> constant invariant 0> 
val[3] = NULL_TREE 
 
Obviously we derive that the new range for "i*i" must be "0" from these 
incorrect val[] results. 

The problem is that the condition for computing val[3] is wrong.
1) If vr0.min == vr0.max and vr1.min != vr1.max, then we have
   vr0.min*vr1.min in val[0] and vr0.min*vr1.max in val[1]. 
2) If vr0.min != vr0.max and vr1.min == vr1.max, then we have
   vr0.min*vr1.min in val[0] and vr0.max*vr0.min in val[2].
3) if vr0.min != vr0.max and vr1.min != vr1.max, then we should
   compute vr0.max*vr1.max.

So the proper condition is (vr0.min != vr0.max && vr1.min != vr1.max).
Bootstrapped on x86_64-linux, testing it there now, and also testing on
i686-linux.  But the bug is pretty obvious I think, so if I don't hear
from anyone, I'm going to commit this after testing completes without
problems.

Gr.
Steven


	* tree-vrp.c (extract_range_from_binary_expr): Fix logics thinko in
	the computation of the four cross productions for "range op range".

Index: tree-vrp.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-vrp.c,v
retrieving revision 2.40
diff -u -3 -p -r2.40 tree-vrp.c
--- tree-vrp.c	13 Jul 2005 22:35:29 -0000	2.40
+++ tree-vrp.c	14 Jul 2005 20:10:58 -0000
@@ -1183,7 +1183,7 @@ extract_range_from_binary_expr (value_ra
 	       ? vrp_int_const_binop (code, vr0.max, vr1.min)
 	       : NULL_TREE;
 
-      val[3] = (vr0.min != vr1.min && vr0.max != vr1.max)
+      val[3] = (vr0.min != vr0.max && vr1.min != vr1.max)
 	       ? vrp_int_const_binop (code, vr0.max, vr1.max)
 	       : NULL_TREE;
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]