This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Fix INTEGER_CST handling in highest_pow2_factor
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: gcc-patches at gcc dot gnu dot org
- Date: Sat, 15 Dec 01 08:32:41 EST
- Subject: Fix INTEGER_CST handling in highest_pow2_factor
This fixes a number of ICE with GNAT on Sparc.
Tested in alphaev56-dec-osf4.0c.
Sat Dec 15 08:29:45 2001 Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
* expr.c (highest_pow2_factor, case INTEGER_CST): Return
BIGGEST_ALIGNMENT for 0.
*** expr.c 2001/12/14 02:16:29 1.399
--- expr.c 2001/12/15 13:31:54
*************** highest_pow2_factor (exp)
*** 5794,5809 ****
case INTEGER_CST:
/* If the integer is expressable in a HOST_WIDE_INT, we can find the
! lowest bit that's a one. If the result is zero, pessimize by
! returning 1. This is overly-conservative, but such things should not
! happen in the offset expressions that we are called with. If
! the constant overlows, we some erroneous program, so return
! BIGGEST_ALIGNMENT to avoid any later ICE. */
! if (TREE_CONSTANT_OVERFLOW (exp))
return BIGGEST_ALIGNMENT;
else if (host_integerp (exp, 0))
{
c0 = tree_low_cst (exp, 0);
! c0 = c0 < 0 ? - c0 : c0;
! return c0 != 0 ? c0 & -c0 : 1;
}
break;
--- 5794,5809 ----
case INTEGER_CST:
/* If the integer is expressable in a HOST_WIDE_INT, we can find the
! lowest bit that's a one. If the result is zero, return
! BIGGEST_ALIGNMENT. We need to handle this case since we can find it
! in a COND_EXPR, a MIN_EXPR, or a MAX_EXPR. If the constant overlows,
! we have an erroneous program, so return BIGGEST_ALIGNMENT to avoid any
! later ICE. */
! if (TREE_CONSTANT_OVERFLOW (exp)
! || integer_zerop (exp))
return BIGGEST_ALIGNMENT;
else if (host_integerp (exp, 0))
{
c0 = tree_low_cst (exp, 0);
! return c0 < 0 ? - c0 : c0;
}
break;