[Bug c/59891] [4.7/4.8/4.9 Regression] ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 21 Jan 2014, jakub at gcc dot gnu.org wrote:

> The outer C_MAYBE_CONST_EXPR comes from:
> #5  0x000000000059abd4 in note_integer_operands (expr=<cond_expr
> 0x7ffff19d8840>) at ../../gcc/c/c-typeck.c:151
> #6  0x00000000005accab in build_conditional_expr (colon_loc=5669,
> ifexp=<integer_cst 0x7ffff18b4620>, ifexp_bcp=false, 
>     op1=<integer_cst 0x7ffff18b4400>, op1_original_type=<tree 0x0>,
> op2=<nop_expr 0x7ffff19c87c0>, op2_original_type=<tree 0x0>)
>     at ../../gcc/c/c-typeck.c:4716
> #7  0x00000000005d99c4 in c_parser_conditional_expression
> (parser=0x7ffff19d9000, after=0x0, omp_atomic_lhs=<tree 0x0>)
>     at ../../gcc/c/c-parser.c:5969
> and there we don't fully fold it.

This code was supposed to have removed C_MAYBE_CONST_EXPRs where they 
could cause problems, through:

      if (int_operands)
        {
          op1 = remove_c_maybe_const_expr (op1);
          op2 = remove_c_maybe_const_expr (op2);
        }

(the relevant note_integer_operands call being conditional on 
int_operands).  So why didn't that work?