http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48641
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #24012|0 |1
is obsolete| |
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-05
14:51:12 UTC ---
Created attachment 25991
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25991
pr48641.c
Slightly more reduced testcase.
The problem is in the thread-ssa-threadupdate.c (redirect_edges) hunk added in
r102053:
rd->dup_block->count += e->count;
rd->dup_block->frequency += EDGE_FREQUENCY (e);
EDGE_SUCC (rd->dup_block, 0)->count += e->count;
create_duplicates on this testcase creates huge number of basic blocks, and
this function adjusts the edges, so that each of these rd->dup_block has two
incoming edges, one 100% EDGE_FREQUENCY (for the first one of these from the
ENTRY successor, another one from some other bb (which will be removed as dead
later on, for the other blocks one of the predecessors is the previous dup
block). Unfortunately this means that rd->dup_block->frequency goes over
BB_FREQ_MAX (the first of these has BB_FREQ_MAX + something, second that plus
something2, etc.) and finally the EDGE_FREQUENCY computation overflows
(e->src->frequency where e->src is the previous rd->dup_block is over 214748
and EDGE_FREQUENCY
multiplies that by 10000). Caping it to BB_FREQ_MAX wouldn't probably work,
because then cfg cleanup that removes all the unreachable blocks would decrease
it too much. Honza?
