This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/16490] segfault while compiling with -fprofile-use
- From: "wilson at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Aug 2004 01:26:13 -0000
- Subject: [Bug rtl-optimization/16490] segfault while compiling with -fprofile-use
- References: <20040712084725.16490.kapalka@icslab.agh.edu.pl>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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