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


  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).