On Thu, 21 Mar 2019, Jason Merrill wrote: > On 3/21/19 9:43 AM, Richard Biener wrote: > > On Thu, 21 Mar 2019, Richard Biener wrote: > > > > > > > > This also avoids the ICE in PR89779 but IMHO is not a real fix. > > > > > > Still it restores a previously active check against released SSA names > > > which now have error_mark_node type rather than NULL. The new way > > > opens up consolidation so I've adjusted tree_nop_conversion plus > > > operand_equal_p which got a defensive check at the same time > > > (and checks for error_mark_node right before that check). > > > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > > > > > The testcase comes with the other patch (but still included below). > > > > Ugh, looks like my defense installed for released SSA names is now > > relied upon by the C++ FE via > > > > #2 0x0000000001864a96 in tree_strip_nop_conversions ( > > exp=<convert_expr 0x7ffff69bc920>) > > at /space/rguenther/src/svn/trunk2/gcc/tree.c:12848 > > #3 0x0000000000ab2d2f in iterative_hash_template_arg ( > > arg=<convert_expr 0x7ffff69bc920>, val=3363282904) > > at /space/rguenther/src/svn/trunk2/gcc/cp/pt.c:1751 > > > > for > > > > <convert_expr 0x7ffff69bc920 > > type <integer_type 0x7ffff68985e8 int public type_6 SI > > size <integer_cst 0x7ffff689c078 constant 32> > > unit-size <integer_cst 0x7ffff689c090 constant 4> > > align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > > 0x7ffff68985e8 precision:32 min <integer_cst 0x7ffff689c030 -2147483648> > > max <integer_cst 0x7ffff689c048 2147483647> > > pointer_to_this <pointer_type 0x7ffff68a19d8>> > > arg:0 <scope_ref 0x7ffff69d0b40 tree_0 > > arg:0 <template_type_parm 0x7ffff69d17e0 i tree_0 type_0 type_6 > > VOID > > align:8 warn_if_not_align:0 symtab:0 alias-set -1 > > canonical-type 0x7ffff69d1150 > > index 0 level 1 orig_level 1 > > chain <type_decl 0x7ffff69d2098 i>> > > arg:1 <identifier_node 0x7ffff69c39c0 c > > normal local bindings <(nil)>>>> > > > > where both the SCOPE_REF and TEMPLATE_TYPE_PARM have NULL > > TREE_TYPE. > > > > So I'll restore the NULL check in tree_nop_conversion. > > > > But since the C++ FE overloads almost every tree field possible > > I wonder whether that STRIP_NOPS in iterative_hash_template_arg > > is a good idea? > > I think it still makes sense; TREE_TYPE of an expression is either a type, > error_mark_node, or NULL_TREE (for type-dependent expressions in a template). > > > Also I hope the FE doesn't call into operand_equal_p with such > > typed trees. > > It shouldn't, we have cp_tree_equal to use instead.
OK, let's see how to use that for PR89790 then... Richard.
