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


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