RFA: PR16490, value profiling ICE

James E Wilson wilson@specifixinc.com
Sun Aug 8 02:24:00 GMT 2004


I have a full analysis in the PR.  This just summaries the info there.

Using -fprofile-use with the IA-64 port can result in a crash in
bitmap_operation during the loop2 pass because we dereferenced a null
pointer in a basic block global_live_at_start field.

Normally, we wouldn't have any life info here since this is before the
life pass.  However, with -fprofile-use we do, because that enables the
value profiling pass, and this calls life_analysis during the
branch_prob (bp) pass.

Since the cfg* routines use the existence of the life info to determine
whether we compute it for new blocks, this means that once we have life
info we need to maintain it for all blocks, or else throw it away once
we are done with it.  Alternatively, we could modify the tests in the
cgf* routines, but I did not seriously consider that alternative.

The routine that causes the problem is cfg_layout_split_block, which
creates a new block, but does not initialize the life info in the new
block if the old block has life info.  The equivalent rtl_split_block
function however does do this.  Therefore, it seems reasonable for
cfg_layout_split_block to do this also.

I have written a patch to do this, and this solves the problem reported
in PR 16490.  I have attached the gcc-3.4.x version of this patch.  The
same problem exists in mainline, and the same patch can fix it.

I also wrote a patch that throws away the life info, and this solves the
PR also.  This is attached to the PR.  I didn't think this was as good
as a solution, but I can accept either solution.

I am also willing to consider other ideas.  I am not too familiar with
the cfg* code, there may be other ways to solve this problem.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.2
Type: text/x-troff-man
Size: 1144 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040808/12574d02/attachment.bin>


More information about the Gcc-patches mailing list