public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
Date: Mon, 02 Mar 2015 05:38:00 -0000 [thread overview]
Message-ID: <bug-65233-4-9clwX67EmF@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65233-4@http.gcc.gnu.org/bugzilla/>
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
next prev parent reply other threads:[~2015-03-02 5:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
2015-02-27 10:32 ` [Bug target/65233] " rguenth at gcc dot gnu.org
2015-02-27 10:41 ` ktkachov at gcc dot gnu.org
2015-02-27 10:53 ` doko at gcc dot gnu.org
2015-02-27 11:46 ` jakub at gcc dot gnu.org
2015-02-27 12:05 ` doko at gcc dot gnu.org
2015-02-27 12:07 ` jakub at gcc dot gnu.org
2015-02-27 20:31 ` aldyh at gcc dot gnu.org
2015-03-01 8:59 ` doko at gcc dot gnu.org
2015-03-01 10:18 ` [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu doko at gcc dot gnu.org
2015-03-01 10:19 ` doko at gcc dot gnu.org
2015-03-01 15:33 ` aldyh at gcc dot gnu.org
2015-03-01 16:56 ` aldyh at gcc dot gnu.org
2015-03-02 4:38 ` law at redhat dot com
2015-03-02 5:22 ` [Bug middle-end/65233] " aldyh at gcc dot gnu.org
2015-03-02 5:38 ` aldyh at gcc dot gnu.org [this message]
2015-03-02 5:49 ` aldyh at gcc dot gnu.org
2015-03-02 5:50 ` aldyh at gcc dot gnu.org
2015-03-02 21:41 ` law at redhat dot com
2015-03-03 19:33 ` aldyh at gcc dot gnu.org
2015-03-04 13:27 ` rguenth at gcc dot gnu.org
2015-03-05 8:38 ` rguenth at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-65233-4-9clwX67EmF@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).