https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 20 Dec 2018, asolokha at gmx dot com wrote: > 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). Ah, thanks for debugging. Obviously the following need to be GTY(()) #ifdef RS6000_GLIBC_ATOMIC_FENV /* Function declarations for rs6000_atomic_assign_expand_fenv. */ static tree atomic_hold_decl, atomic_clear_decl, atomic_update_decl; #endif ppc folks?
