[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968




------- Comment #9 from mkuvyrkov at gcc dot gnu dot org  2006-08-02 13:44 -------
(In reply to comment #8)
> The time that this started occurring looks to be about the time that Maxim was
> making scheduling changes for IA64 speculation.  Maxim could you look at this
> bug and see if it is related to any of your changes to IA64 scheduling?  I did
> a little analysis and it looks like we are merging/concatinated two basic
> blocks (3 and 7) but we wind up with a NOTE_INSN_BASIC_BLOCK for block 7 in the
> middle of the merged basic block 3.

That's my bug, sorry.
In this testcase we hit a rare case when we end up with dead code during
scheduling.

More specifically:
--------------------------
(insn 127 128 108 3 (set (reg:DI 332 ar.lc)
        (reg:DI 35 r35)) 5 {*movdi_internal} (nil)
    (expr_list:REG_DEAD (reg:DI 35 r35)
        (nil)))
(call_insn/j 108 127 146 3 (call (mem:DI (symbol_ref:DI ("cr") [flags 0x3]
<function_decl 0x2000000000449500 cr>) [0 S8 A64])
        (const_int 0 [0x0])) 321 {sibcall_nogp} (nil)
    (expr_list:REG_EH_REGION (const_int 0 [0x0])
        (nil))
    (expr_list:REG_DEP_TRUE (use (reg:DI 320 b0))
        (expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
            (nil))))
-----------------------

More specifically, a call (108) - which will exit from the function - is
scheduled before insn (127) thus making it dead.  To schedule the dead insn we
should create an empty basic block right after call.  But I've made a mistake
and current code creates new basic block just before it.

While debugging one of the above testcases I've also discovered another problem
in switching between blocks in the ebb.  While switching to the next block we
should skip empty ones so that jumps won't be moved across blocks when not
particularly needed.

The attached patch works for all testcases and as soon as regtesting is over
I'll post it to gcc-patches list.

> 
> (I tried to add mkuvyrkov@ispras.ru to the CC list but Bugzilla wouldn't do it.

It is because mkuvyrkov@ispras.ru doesn't have a Bugzilla account.
You could've add mkuvyrkov@gcc.gnu.org .

Thanks for the testcases.  It is good to have several testcases as only one of
them revealed the second problem.


Thanks,
Maxim


-- 

mkuvyrkov at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkuvyrkov at gcc dot gnu dot
                   |                            |org
         AssignedTo|unassigned at gcc dot gnu   |mkuvyrkov at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-07-29 10:57:44         |2006-08-02 13:44:23
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



Reply to: