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

Reply via email to