http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the problem is nested C_MAYBE_CONST_EXPRs, and c_fully_fold_internal
doesn't seem to fully fold the operands of this.
The inner C_MAYBE_CONST_EXPR comes from:
#5 0x0000000000608b40 in c_wrap_maybe_const (expr=<trunc_mod_expr
0x7ffff19b9870>, non_const=false) at ../../gcc/c-family/c-common.c:4455
#6 0x00000000005ac3a3 in build_conditional_expr (colon_loc=5669,
ifexp=<integer_cst 0x7ffff18b4620>, ifexp_bcp=false,
op1=<integer_cst 0x7ffff18b4400>, op1_original_type=<tree 0x0>,
op2=<trunc_mod_expr 0x7ffff19b9870>, op2_original_type=<tree 0x0>)
at ../../gcc/c/c-typeck.c:4577
#7 0x00000000005d99c4 in c_parser_conditional_expression
(parser=0x7ffff19d9000, after=0x0, omp_atomic_lhs=<tree 0x0>)
at ../../gcc/c/c-parser.c:5969
and build_conditional_expr clearly calls c_fully_fold on expressions before
(optionally) passing them to c_wrap_maybe_const.
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.
So, should the fix be to call c_fully_fold on expr before creating the
C_MAYBE_CONST_EXPR?
