https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
--- Comment #1 from qinzhao at gcc dot gnu.org ---
the reason for the ICE is:
in C FE, there is a C_MAYBE_CONST_EXPR that is generated for converting the
parameter "x" to integer type before comparing with integer constant 0 as:
arg:0 <ne_expr 0xfffff5af3390 type <integer_type 0xfffff57305e8
int>
arg:0 <c_maybe_const_expr 0xfffff5af3368 type <integer_type
0xfffff57305e8 int>
arg:1 <convert_expr 0xfffff563da20 type <integer_type
0xfffff57305e8 int>
arg:0 <parm_decl 0xfffff56d8bb8 x>>>
arg:1 <integer_cst 0xfffff56212c0 constant 0>
t.c:14:16 start: t.c:14:16 finish: t.c:14:16> arg:1 <parm_decl
0xfffff56d8c40 a> arg:2 <parm_decl 0xfffff56d8cc8 b>
Without generating call to .ACCESS_WITH_SIZE, this C_MAYBE_CONST_EXPR is
removed in the IR that is passed to middle-end.
However, when generating call to .ACCESS_WITH_SIZE, the C_MAYBE_CONST_EXPR
become parts of the operands of this call to .ACCESS_WITH_SIZE. and are not
removed from the call to .ACCESS_WITH_SIZE. therefore causing the ICE in
gimplification phase.
Need to study how to remove the C_MAYBE_CONST_EXPR from the new generated call
to .ACCESS_WITH_SIZE.
