File tree_expr_nonzero.patch of Package libgcj41

Overview Repositories Revisions Requests Users Attributes Meta

File tree_expr_nonzero.patch of Package libgcj41

While working on some improvements to our VRP code I found this
lovely latent bug in fold-const.c

Given a widening type conversion where the inner value is nonzero, we
can statically determine that the result will be nonzero as well.
Pretty simple stuff.  Unfortunately, the sense of the comparison of
the width of the inner and outer types got reversed.

So we had a type conversion where the inner type was wider than the
outer type.  We knew the inner type had a nonzero value (2 in fact),
but converting it to the narrower outer type (a single bit type) would
lose the nonzero bits, yet we claimed the result would have a nonzero
value.  Opps.

No new test as this was discovered by some existing tests in the
testsuite when some minor VRP enhancements were enabled.

Bootstrapped and regression tested on i686-pc-linux-gnu.

* fold-const.c (tree_expr_nonzero_p): Fix thinko.

Index: gcc/fold-const.c
===================================================================
*** gcc/fold-const.c	(revision 110848)
--- gcc/fold-const.c	(working copy)
*************** tree_expr_nonzero_p (tree t)
*** 11256,11262 ****
  	tree inner_type = TREE_TYPE (TREE_OPERAND (t, 0));
  	tree outer_type = TREE_TYPE (t);
  
! 	return (TYPE_PRECISION (inner_type) >= TYPE_PRECISION (outer_type)
  		&& tree_expr_nonzero_p (TREE_OPERAND (t, 0)));
        }
        break;
--- 11256,11262 ----
  	tree inner_type = TREE_TYPE (TREE_OPERAND (t, 0));
  	tree outer_type = TREE_TYPE (t);
  
! 	return (TYPE_PRECISION (outer_type) >= TYPE_PRECISION (inner_type)
  		&& tree_expr_nonzero_p (TREE_OPERAND (t, 0)));
        }
        break;

Places

File tree_expr_nonzero.patch of Package libgcj41

Places