[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