[Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
aldyh at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Mar 2 05:38:00 GMT 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65233
--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #14)
> Presumably this is a case where a block has become unreachable? Or is it a
> case where the block previously had multiple preds, then by way of jump
> threading we've got just a single pred and ultimately we try to merge it
> with its single predecessor?
>
> In the former case, I'd expect cleanup_tree_cfg_noloop (called from
> cleanup_tree_cfg) to have removed the unreachable block(s).
>
> Just to be clear, I'm not saying the patch is wrong, I'm just trying to
> understand the events that led to a PHI with no args and whether or not it
> should have already been cleaned up.
That's the thing, walk_ssa_copies which is the one ICEing, is getting called
_while_ doing the cleanup. So yeah, cleanup_tree_cfg_noloop is supposed to
clean this up, but that's exactly where we're ICEing ;-).
See the backtrace
#0 0x00000000011f6101 in tree_nop_conversion (exp=0xafafafafafafafaf)
at /source/gcc/gcc/tree.c:11792
#1 0x00000000011f639c in tree_strip_nop_conversions (
exp=<error reading variable: Cannot access memory at address
0xafafafafafafafaf>) at /source/gcc/gcc/tree.c:11831
#2 0x00000000011d2db0 in integer_zerop (expr=0xafafafafafafafaf)
at /source/gcc/gcc/tree.c:2218
#3 0x0000000000cb1d12 in walk_ssa_copies (op=<ssa_name 0x7ffff008be58>,
global_visited=0x7fffffffd828)
at /source/gcc/gcc/ipa-polymorphic-call.c:848
#4 0x0000000000cb1fed in
ipa_polymorphic_call_context::ipa_polymorphic_call_context
(this=0x7fffffffd8b0,
fndecl=<function_decl 0x7fffeffe9500 prep_record_enabled>,
ref=<obj_type_ref 0x7ffff0088780>, stmt=<gimple_call 0x7ffff008fd80>,
instance=0x0) at /source/gcc/gcc/ipa-polymorphic-call.c:909
#5 0x0000000000bbf216 in possible_polymorphic_call_targets (
ref=<obj_type_ref 0x7ffff0088780>, call=<gimple_call 0x7ffff008fd80>,
completep=0x7fffffffd91f, cache_token=0x0)
at /source/gcc/gcc/ipa-utils.h:120
#6 0x0000000000bb4bf9 in gimple_fold_call (gsi=0x7fffffffdc10, inplace=false)
at /source/gcc/gcc/gimple-fold.c:3094
#7 0x0000000000bb709c in fold_stmt_1 (gsi=0x7fffffffdc10, inplace=false,
valueize=0xbb7672 <no_follow_ssa_edges(tree_node*)>)
at /source/gcc/gcc/gimple-fold.c:3676
#8 0x0000000000bb76ec in fold_stmt (gsi=0x7fffffffdc10)
at /source/gcc/gcc/gimple-fold.c:3804
#9 0x0000000000f2bce9 in replace_uses_by (name=<ssa_name 0x7ffff0092f78>,
val=<ssa_name 0x7ffff008be58>) at /source/gcc/gcc/tree-cfg.c:1836
#10 0x0000000000f2c164 in gimple_merge_blocks (
a=<basic_block 0x7ffff00a2e38 (47)>, b=<basic_block 0x7ffff0086a28 (13)>)
at /source/gcc/gcc/tree-cfg.c:1922
#11 0x00000000009f5310 in merge_blocks (a=<basic_block 0x7ffff00a2e38 (47)>,
b=<basic_block 0x7ffff0086a28 (13)>) at /source/gcc/gcc/cfghooks.c:769
#12 0x0000000000f43fdb in cleanup_tree_cfg_bb (
bb=<basic_block 0x7ffff00a2e38 (47)>)
at /source/gcc/gcc/tree-cfgcleanup.c:675
#13 0x0000000000f4405a in cleanup_tree_cfg_1 ()
at /source/gcc/gcc/tree-cfgcleanup.c:707
#14 0x0000000000f441b6 in cleanup_tree_cfg_noloop ()
at /source/gcc/gcc/tree-cfgcleanup.c:765
#15 0x0000000000f442c2 in cleanup_tree_cfg ()
etc
etc
More information about the Gcc-bugs
mailing list