[Bug rtl-optimization/60866] [4.7/4.8/4.9/4.10 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
abel at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Apr 28 09:01:00 GMT 2014
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866
Andrey Belevantsev <abel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org
--- Comment #3 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
Created attachment 32692
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32692&action=edit
draft patch
An interesting case so I'd leave more detailed notes. We are scheduling a
region that has a diamond like this:
bb 3 --
| \
bb 4 \
/ \ \
bb 5 bb 6 /
\ / /
bb 7 --
After scheduling bb 3 we proceed to bb 4 and bb 7 simultaneously. Bbs 5 and 6
have identical insns. While having a fence at the end of bb 4, we unify these
insns to one and get empty bbs 5 and 6 at once. While simplifying this, we end
up with a conditional jump ending bb 4 turning into an unconditional one
leading to bb 7 (via redirect_edge_and_branch). This jump is the new insn so
should be initialized. We try to get a seqno for this jump from surrounding
unscheduled code (via get_seqno_for_a_jump), but both bbs 4 and 7 are already
completely scheduled. Thus we ICE.
The only unscheduled insn in this region is the old conditional jump. But it
is no longer with us while we're trying to init the new jump it turned into.
The easy solution is to remove the assert and to change it into something like
"seqno = 42;". This fixes the test but we will never be able to catch bugs in
this function again. The preferred solution will be to pass down the old jump
seqno to the initializing function so it would take it as the new jump seqno
only in this particular case. That means changing a number of
sel_init_new_insn callers. But, if we are now allowed to have default
parameters (do we?), this simplifies things.
Attached is the draft patch (the function comments is not yet updated, C++
default parameters are used).
More information about the Gcc-bugs
mailing list