public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "wilson at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/16490] segfault while compiling with -fprofile-use Date: Sun, 08 Aug 2004 01:26:00 -0000 [thread overview] Message-ID: <20040808012613.29410.qmail@sourceware.org> (raw) In-Reply-To: <20040712084725.16490.kapalka@icslab.agh.edu.pl> ------- Additional Comments From wilson at gcc dot gnu dot org 2004-08-08 01:26 ------- This dies in bitmap_operation because we were called with a block with a null global_live_at_start field. This happens during the loop2 pass, which is before the life pass, so normally there shouldn't be any life info here. However, the value profiling pass does run life_analysis also, so if we are doing value profiling, we will have life info starting with the branch_prob (bp) pass. Since the cfg* routines check the global_live_at_start field of a block to determine whether it should update life info, we either need to update this field in all blocks once it is created, or else we need to eliminate the info after we are done using it. (Or alternatively, modify the tests used in the cfg* routines, but I didn't seriously consider that alternative.) The exact circumstances that cause the crash happen in loop_optimizer_init. First we have a call chain loop_optimizer_init split_edge cfglayout_split_edge create_basic_block and now we have one basic block that does not have life info, while all others do. Then we have the call chain loop_optimizer_init flow_loops_find canonicalize_loop_headers make_forwarder_block cfg_layout_split_block rtl_split_block propate_block init_propagate_block_info bitmap_operation and we die because one block has life info and the other doesn't. I see two ways to fix this. We can zero out the life info when we are done with the value profiling pass. Or we can modify cfglayout_split_edge to set the global_live_at_start field of the new basic block. Since the rtl_split_edge function already does this, this seems like a reasonable thing to do. I can reproduce the same problem in gcc-3.5 using the parse.i file without the parse.gcda file. The call chain is a bit different, but it is the same problem, and fixed with the same solution. -- What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Last reconfirmed|2004-08-05 15:26:05 |2004-08-08 01:26:12 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16490
next prev parent reply other threads:[~2004-08-08 1:26 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-07-12 8:47 [Bug rtl-optimization/16490] New: " kapalka at icslab dot agh dot edu dot pl 2004-07-12 8:50 ` [Bug rtl-optimization/16490] " kapalka at icslab dot agh dot edu dot pl 2004-07-12 8:51 ` kapalka at icslab dot agh dot edu dot pl 2004-07-12 14:26 ` pinskia at gcc dot gnu dot org 2004-08-05 15:26 ` belyshev at lubercy dot com 2004-08-08 1:26 ` wilson at gcc dot gnu dot org 2004-08-08 1:26 ` wilson at gcc dot gnu dot org [this message] 2004-08-11 20:05 ` cvs-commit at gcc dot gnu dot org 2004-08-11 20:08 ` cvs-commit at gcc dot gnu dot org 2004-08-11 20:10 ` wilson at gcc dot gnu dot org 2004-08-11 21:05 ` pinskia at gcc dot gnu dot org 2004-08-16 22:03 ` wilson at gcc dot gnu dot org 2004-08-17 0:14 ` wilson at gcc dot gnu dot 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=20040808012613.29410.qmail@sourceware.org \ --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: linkBe 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).