Optimization bug

[Jeffrey A Law]

  > [snip]
  > The problem in short:
  > "./a.out 1234" prints "192" instead of the correct answer "680" for some
  > optimization levels.
  > 
  > The problem appears to be an invalid transformation in combine.c.  More
  > specifically, num_sign_bit_copies returns 32 for an rtx of the form
  > (udiv:SI (reg:SI 28) (reg:SI 24)), where reg 28 is equal to (const_int -1).
  > 
  > The patch below fixes the test case.  The result of the division is always
  > smaller than the first operand, which means that if the sign bit of the
  > first operand is zero, its number of copies is a valid approximation of the
  > number of sign bit copies in the result.  The same is not true if the sign
  > bit is one.
  > 
  > While looking at num_sign_bit_copies, I noticed other possible problems.
  > Some of the optimizations that are being done rely on being able to perform
  > operations on a value that is "bitwidth" bits wide.  There exist tests for
  > "bitwidth <= HOST_BITS_PER_WIDE_INT" to verify that these operations can
  > be done on the host.  However, in a number of places the code will not
  > compute a conservative result if HOST_BITS_PER_WIDE_INT is too narrow, but
  > return a more optimistic value, which seems incorrect.  I hope I caught all
  > cases in the patch below.
  > 
  > Bernd
  > 
  > 	* combine.c (num_sign_bit_copies): In NEG, MULT, DIV and MOD cases,
  > 	when a test can't be performed due to limited width of
  > 	HOST_BITS_PER_WIDE_INT, use the more conservative approximation.
  > 	Fix UDIV case for cases where the first operand has the highest bit
  > 	set.
Thanks.  I've installed this patch.

jeff