Hi!
This testcase was fixed in 4.2+ with the PR27116 patch.
So, either we want to backport that and patches that it depends on,
or the following should fix this case as well.
If negate_expr doesn't optimize negation of an INTEGER_CST or REAL_CST,
it falls back to the default fold_build1 (NEGATE_EXPR, TREE_TYPE (t), t),
which in turn calls fold_unary. As t here is known to be INTEGER_CST
or REAL_CST, all that it does is:
case NEGATE_EXPR:
if (negate_expr_p (arg0))
return fold_convert (type, negate_expr (arg0));
/* Convert - (~A) to A + 1. */
if (INTEGRAL_TYPE_P (type) && TREE_CODE (arg0) == BIT_NOT_EXPR)
return fold_build2 (PLUS_EXPR, type, TREE_OPERAND (arg0, 0),
build_int_cst (type, 1));
return NULL_TREE;
so either recurses again with the same argument, or returns NULL
(because arg0 is certainly not BIT_NOT_EXPR). Just calling
build1 instead of fold_build1 will make the endless recursion impossible,
while won't change behavior in the rest of cases.
2006-12-29 Jakub Jelinek <jakub@redhat.com>
PR middle-end/30286
* fold-const.c (negate_expr): Don't call fold_build1
for INTEGER_CST or REAL_CST.
* gcc.dg/pr30286.c: New test.