gcc.c-torture/compile/990801-2.c

Jeffrey A Law law@cygnus.com
Thu Sep 23 14:17:00 GMT 1999


  In message <jehfm4vv8t.fsf@hawking.suse.de>you write:
  > The following patch seems to fix the bug that is triggered by the
  > testsuite, but I'm not sure if it is ok for all cases since INSN is still
  > used further down the function after it has been deleted.
  > 
  > 
  > Fri Aug 13 12:10:31 1999  Andreas Schwab  <schwab@suse.de>
  > 
  > 	* cse.c (cse_insn): After converting the jump to an unconditional
  > 	jump and deleting the following insns check that the first insn
  > 	hasn't just been deleted.
This is actually a *very* interesting problem.  And I'd like to hear some
more opinions before installing either of your patches [ I actually think
there's a simpler solution to the direct problem y'all were trying to solve. ]

What happens is we initially have a conditional jump.  CSE determines that
the condition for the jump is always true, so we turn it into an unconditional
jump.

When we do such a conversion, we delete all the insns after the converted jump
up to the next BARRIER or CODE_LABEL.

One of the insns we delete happens to be another jump which happens to have
the last reference to label before the jump we were converting.  ie, the jump
we are converting just became unreachable and will be deleted.

Hmmm, maybe rtl will help.

(code_label 31 8 33 6 "" [num uses: 1])

[ ... ]

(jump_insn 20 18 22 (set (pc)
        (label_ref 47)) -1 (nil)
    (nil))

(jump_insn 22 20 27 (set (pc)
        (if_then_else (ne (reg/s/v:SI 94)
                (const_int 2 [0x2]))
            (label_ref 31)
            (pc))) 47 {bleu+1} (nil)
    (nil))

[ ... ]

We just converted jump_insn 20 from a conditional jump into an unconditional
jump.  We will start deleting instructions at jump_insn 22.

jump_insn 22 has the last reference to label 31.  So we proceed to also delete
all the insns starting at code_label 31.  Which includes jump_insn 20.

This causes an abort because we try to emit a barrier after the deleted
jump_insn 20.  However, that's not what I'm concerned about.

Assume for the moment we deal with BARRIER in some sane manner.  What should
the rest of CSE insn do when the insn we are looking at gets deleted?

It may be OK to just let cse_insn finish in the normal fashion given that
there's really nothing left for it to do with (set (pc) (label).  Or maybe
the thing to do is return and not take any chances with cse_insn doing
anything weird when presented with a deleted insn.  

Opinions anyone?

jeff






More information about the Gcc-patches mailing list