This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/16490] segfault while compiling with -fprofile-use


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]