[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

asolokha at gmx dot com gcc-bugzilla@gcc.gnu.org
Thu Dec 20 09:06:00 GMT 2018


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134

--- Comment #15 from Arseny Solokha <asolokha at gmx dot com> ---
In build_atomic_assign() we have

 4222   /* Create the expressions for floating-point environment
 4223      manipulation, if required.  */
 4224   bool need_fenv = (flag_trapping_math
 4225                     && (FLOAT_TYPE_P (lhs_type) || FLOAT_TYPE_P
(rhs_type)));
 4226   tree hold_call = NULL_TREE, clear_call = NULL_TREE, update_call =
NULL_TREE;
 4227   if (need_fenv)
 4228     targetm.atomic_assign_expand_fenv (&hold_call, &clear_call,
&update_call);

which gets us into this block in rs6000_atomic_assign_expand_fenv():

 38906   if (!TARGET_HARD_FLOAT)
 38907     {
 38908 #ifdef RS6000_GLIBC_ATOMIC_FENV

<…>

 38951       *hold = build_call_expr (atomic_hold_decl, 1, fenv_addr);
 38952       *clear = build_call_expr (atomic_clear_decl, 0);
 38953       *update = build_call_expr (atomic_update_decl, 1,
 38954                                  fold_convert (const_double_ptr,
fenv_addr));
 38955 #endif
 38956       return;
 38957     }

(it's the first build_call_expr() that fails deeper in the call stack in
comment 5), so ICEs from both comment 0 and comment 5 naturally go away w/
-fno-trapping-math. And we simply bail out from building these atomic FENV
manipulation calls w/ target glibc < 2.19, according to
RS6000_GLIBC_ATOMIC_FENV definition, which might explain why not all compilers
necessary crash.

I believe ICEs in comment 0 and comment 5 are unrelated after all, as in the
latter case we seem to have a GC-related memory corruption which I cannot
trigger w/ the testcase from comment 0:

==13546== Invalid read of size 1
==13546==    at 0xFD336F: contains_struct_check (tree.h:3270)
==13546==    by 0xFD336F: build_call_expr_loc_array(unsigned int, tree_node*,
int, tree_node**) (tree.c:11398)
==13546==    by 0xFD35D1: build_call_expr(tree_node*, int, ...) (tree.c:11448)
==13546==    by 0x10530B3: rs6000_atomic_assign_expand_fenv(tree_node**,
tree_node**, tree_node**) (rs6000.c:38951)
==13546==    by 0x7A8C68: build_atomic_assign(unsigned int, tree_node*,
tree_code, tree_node*, bool) (c-typeck.c:4228)
==13546==    by 0x7A96B1: build_unary_op(unsigned int, tree_code, tree_node*,
bool) (c-typeck.c:4670)
==13546==    by 0x7D3826: c_parser_postfix_expression_after_primary(c_parser*,
unsigned int, c_expr) (c-parser.c:9648)
==13546==    by 0x7C5C54: c_parser_postfix_expression(c_parser*)
(c-parser.c:9215)
==13546==    by 0x7CF5EA: c_parser_unary_expression(c_parser*)
(c-parser.c:7358)
==13546==    by 0x7D05D7: c_parser_cast_expression(c_parser*, c_expr*)
(c-parser.c:7200)
==13546==    by 0x7D0824: c_parser_binary_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:7003)
==13546==    by 0x7D174B: c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:6737)
==13546==    by 0x7D1E0B: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.c:6654)
==13546==  Address 0x1fe4421 is not stack'd, malloc'd or (recently) free'd

(here I changed ggc-min-expand value to 0).


More information about the Gcc-bugs mailing list