[Bug middle-end/20177] New: ICE in schedule-insns for -O2 -fmodulo-sched

[Bug middle-end/20177] New: ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

The options "-O2 -fmodulo-sched" result in an internal compiler error on
powerpc*-linux for most benchmarks in SPEC CPU2000, and also for several
tests from gcc.c-torture/compile.  Failing tests from that directory with
-m32 are 20000403-1.c, 20040621-1.c, 920723-1.c, 920825-2.c, 931003-1.c,
961004-1.c, 961019-1.c, and 991214-1.c.  They all ICE in the same place with:
                                                                                
20000403-1.c:18: internal compiler error: in schedule_insns, at sched-rgn.c:2549
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

-- 
           Summary: ICE in schedule-insns for -O2 -fmodulo-sched
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janis at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-*-linux-gnu


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-23 18:52 -------
Hmm, that means someone is not updating the dead count correct:
            gcc_assert (deaths_in_region[rgn]
                        == count_or_remove_death_notes (blocks, 0));

Maybe related to the fixed PR 17933.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-03-04 18:36 -------
I vastly overstated the failures in SPEC CPU2000 for this problem: ammp fails
with both -m32 and -m64, and fma3d and sixtrack fail with -m32.

Mainline GCC built last night still gets all of the testsuite and CPU2000
failures.  The 4.0 compiler built last night now passes all of the named C
torture tests, but fails buildling ammp, fma3d, and sixtrack with "internal
consistency failure"; when I get some time I'll get a minimized test case
for that.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-03-07 19:37 -------
Created an attachment (id=8352)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8352&action=view)
minimized test case

This test case is minimized from ammp and gets "fatal error: internal
consistency failure" when compiled with "-m32 -O2 -fmodulo-sched" with
the 4.0 branch built last for powerpc64-unknown-linux-gnu.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-03-14 20:25 -------
Mainline and 4.0 branch still fail the small testcase with "fatal error:
internal consistency failure" when built for powerpc-linux (not just
powerpc64-linux).  The failure begins with the following patch, added
before the 4.0 branch was created:
                                                                                
2005-02-19  Steven Bosscher  <stevenb@suse.de>
                                                                                
        PR middle-end/19698
        * function.h (struct function): New field `max_loop_depth'.
        * cfgloop.c (establish_preds): Update maximum loop depth seen so far.
        (flow_loops_find): Reset the max loop depth count before finding loops.
        * flow.c (MAX_LIVENESS_ROUNDS): New constant.
        (update_life_info_in_dirty_blocks): Remove 2002-05-28 workaround.
        (calculate_global_regs_live): Make sure the loop will terminate
        when the initial sets are not empty.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stevenb at suse dot de


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[steven at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-03-16 00:57:36
               date|                            |


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-03-16 00:57 -------
I really doubt my patch is to blame for this.  This patch has been on 
the hammer branch for ages, so it was in the system compiler of every 
SUSE distribution released in the last 2 years. 
 
Probably SMS is not updating something correctly.  Hard to tell what, 
unfortunately, because the SMS dump is not very good (does not dump 
RTL with basic blocks, see patch below, and it dumps *before* updating 
liveness). 
 
Index: passes.c 
=================================================================== 
RCS file: /cvs/gcc/gcc/gcc/passes.c,v 
retrieving revision 2.73 
diff -u -r2.73 passes.c 
--- passes.c    1 Mar 2005 13:44:45 -0000       2.73 
+++ passes.c    16 Mar 2005 00:54:13 -0000 
@@ -577,7 +577,7 @@ 
   /* We want to be able to create new pseudos.  */ 
   no_new_pseudos = 0; 
   sms_schedule (dump_file); 
-  close_dump_file (DFI_sms, print_rtl, get_insns ()); 
+  close_dump_file (DFI_sms, print_rtl_with_bb, get_insns ()); 
 
 
   /* Update the life information, because we add pseudos.  */ 

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-03-16 01:01 -------
This is enough for me to trigger the bug.  The malloc is needed, 
probably it makes sure V and vector don't alias, or something like 
that. 
 
extern void * malloc (long); 
 
int n; 
float (*vector)[]; 
 
void 
foo (float *V) 
{ 
  int i, used = 0; 
 
  vector = malloc (i * sizeof (float)); 
  for (i = 0; i < n; i++) 
    *V += (*vector)[i]; 
} 
 

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-03-16 01:05 -------
Mostafa, would you please take a look at this?  If you don't get to it first
I'll try it with your recent SMS changes.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mustafa at il dot ibm dot
                   |                            |com


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-03-16 01:10 -------
For me the fatal error now happens in a block starting with this: 
 
Breakpoint 6, verify_wide_reg (regno=136, bb=0x400a5a50) 
at ../../mainline/gcc/flow.c:494 
494       fatal_error ("internal consistency failure"); 
(gdb) p debug_bb (bb) 
;; basic block 2, loop depth 1, count 0 
;; prev block 7, next block 3 
;; pred:       7 [100.0%]  (fallthru) 2 [89.0%]  (dfs_back) 
;; succ:       2 [89.0%]  (dfs_back) 3 [11.0%]  (fallthru,loop_exit) 
;; Registers live at start:  1 [1] 31 [31] 67 [ap] 122 126 138 142 
(code_label:HI 33 56 34 2 4 "" [2 uses]) 
(note:HI 34 33 37 2 [bb 2] NOTE_INSN_BASIC_BLOCK) 
(insn:HI 37 34 42 2 (set (reg:SF 135) 
        (mem/s:SF (reg/f:SI 122 [ ivtmp.11 ]) [4 S4 A8])) 224 
{*movsf_hardfloat} (nil) 
    (nil)) 
(insn:HI 42 37 65 2 (set (reg/f:SI 122 [ ivtmp.11 ]) 
        (plus:SI (reg/f:SI 122 [ ivtmp.11 ]) 
            (const_int 4 [0x4]))) 31 {*addsi3_internal1} 
(insn_list:REG_DEP_ANTI 37 (nil)) 
    (nil)) 
(insn:HI 65 42 38 2 (set (reg:SF 138) 
        (reg:SF 136)) 224 {*movsf_hardfloat} (insn_list:REG_DEP_TRUE 38 (nil)) 
    (expr_list:REG_DEAD (reg:SF 136) 
        (nil))) 
 
So reg 136 dies in insn 65, but it is not even live there according 
to the live-on-entry set...? 
 
 

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[echristo at redhat dot com]

------- Additional Comments From echristo at redhat dot com  2005-03-16 01:15 -------
Fairly certain the REG_DEAD note is wrong since I can't see a way for 136 to die
in that insn (on read?).

Where'd the note get set?

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-03-16 01:24 -------
This is at the point where die.  Block 2 and block 7 both set reg 136.  
Block 2 uses it, and the predecessors of block 2 are block 2 and block 7.  
Reg 136 is in liveout(2).  But it is not in liveout(7) for some reason.  
That is just wrong, reg 136 is live on exit of block 7, too.  
  
(gdb) p debug_bb_n(7)  
;; basic block 7, loop depth 0, count 0  
;; prev block 1, next block 2  
;; pred:       1 [100.0%]  (fallthru)  
;; succ:       2 [100.0%]  (fallthru)  
;; Registers live at start:  1 [1] 31 [31] 67 [ap] 122 126 138 142  
(note 108 106 93 7 [bb 7] NOTE_INSN_BASIC_BLOCK)  
(insn 93 108 107 7 (set (reg:SF 135)  
        (mem/s:SF (reg/f:SI 122 [ ivtmp.11 ]) [4 S4 A8])) 224  
{*movsf_hardfloat} (nil)  
    (nil))  
(insn 107 93 97 7 (set (reg:SI 142 [ n.3 ])  
        (plus:SI (reg:SI 142 [ n.3 ])  
            (const_int -1 [0xffffffffffffffff]))) 31 {*addsi3_internal1} (nil)  
    (nil))  
(insn 97 107 95 7 (set (reg:SF 136)  
        (plus:SF (reg:SF 138)  
            (reg:SF 135))) 129 {*rs6000.md:4493} (insn_list:REG_DEP_TRUE 93  
(nil))  
    (nil))  
(insn 95 97 56 7 (set (reg/f:SI 122 [ ivtmp.11 ])  
        (plus:SI (reg/f:SI 122 [ ivtmp.11 ])  
            (const_int 4 [0x4]))) 31 {*addsi3_internal1}  
(insn_list:REG_DEP_ANTI 93 (nil))  
    (nil))  
;; Registers live at end:  1 [1] 31 [31] 67 [ap] 122 126 138 142  
$12 = (struct basic_block_def *) 0x400b2258  
(gdb) p debug_bb_n(2)  
;; basic block 2, loop depth 1, count 0  
;; prev block 7, next block 3  
;; pred:       7 [100.0%]  (fallthru) 2 [89.0%]  (dfs_back)  
;; succ:       2 [89.0%]  (dfs_back) 3 [11.0%]  (fallthru,loop_exit)  
;; Registers live at start:  1 [1] 31 [31] 67 [ap] 122 126 138 142  
(code_label:HI 33 56 34 2 4 "" [2 uses])  
(note:HI 34 33 37 2 [bb 2] NOTE_INSN_BASIC_BLOCK)  
(insn:HI 37 34 42 2 (set (reg:SF 135)  
        (mem/s:SF (reg/f:SI 122 [ ivtmp.11 ]) [4 S4 A8])) 224  
{*movsf_hardfloat} (nil)  
    (nil))  
(insn:HI 42 37 65 2 (set (reg/f:SI 122 [ ivtmp.11 ])  
        (plus:SI (reg/f:SI 122 [ ivtmp.11 ])  
            (const_int 4 [0x4]))) 31 {*addsi3_internal1}  
(insn_list:REG_DEP_ANTI 37 (nil))  
    (nil))  
(insn:HI 65 42 38 2 (set (reg:SF 138)  
        (reg:SF 136)) 224 {*movsf_hardfloat} (insn_list:REG_DEP_TRUE 38 (nil))  
    (expr_list:REG_DEAD (reg:SF 136)  
        (nil)))  
(insn:HI 38 65 74 2 (set (reg:SF 136)  
        (plus:SF (reg:SF 138)  
            (reg:SF 135))) 129 {*rs6000.md:4493} (insn_list:REG_DEP_TRUE 37  
(nil))  
    (expr_list:REG_DEAD (reg:SF 135)  
        (nil)))  
(jump_insn:HI 74 38 57 2 (parallel [  
            (set (pc)  
                (if_then_else (ne (reg:SI 142 [ n.3 ])  
                        (const_int 1 [0x1]))  
                    (label_ref 33)  
                    (pc)))  
            (set (reg:SI 142 [ n.3 ])  
                (plus:SI (reg:SI 142 [ n.3 ])  
                    (const_int -1 [0xffffffffffffffff])))  
            (clobber (scratch:CC))  
            (clobber (scratch:SI))  
        ]) 377 {*ctrsi_internal1} (nil)  
    (expr_list:REG_UNUSED (scratch:SI)  
        (expr_list:REG_UNUSED (scratch:CC)  
            (nil))))  
;; Registers live at end:  1 [1] 31 [31] 67 [ap] 122 126 136 138 142  
$13 = (struct basic_block_def *) 0x400a5a50  
 
The note comes from the flow update in rest_of_handle_sms. 

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[mustafa at il dot ibm dot com]

------- Additional Comments From mustafa at il dot ibm dot com  2005-03-16 09:36 -------
I suppose that the REG_DEAD for 136 in insn 65 is correct, because the next insn
is a DEF of 136. So the problem here is that 136 is not in the liveout of BB 7.
 I can guess that insn 97 that defines 136 is added by SMS, but isn't it the job
of update_flow_info to update the liveout of BB 7? At least that what I was
excepting when called it from rest_of_handle_sms.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[mustafa at il dot ibm dot com]

------- Additional Comments From mustafa at il dot ibm dot com  2005-03-16 12:05 -------
After a bit more debugging I found out that the error caused due to copying the
REG_DEAD note with the instructions when we are generating the prologues and
epilogues in SMS.  The REG_DEAD is correct in the inter-block view but not
inside the block; but update_live_info looks inside the blocks and verify the
information for each block and that where we are wrong.  
The fix is to prevent us from copying the REG_DEAD note in such a case.  We
should also look for other  REG_ notes that we shouldn't be copying to
prologue/epilogue. 
REG_USE for example should still be copies. 

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[mustafa at il dot ibm dot com]

------- Additional Comments From mustafa at il dot ibm dot com  2005-03-16 17:45 -------
For some reason the REG_DEAD is not the cause of the failure 
it is the fact that the SMSed basic-block wasn't mark dirty for
update_life_info that come after it. doing so fixes the failure 
even with REG_DEAD is still in that insn.  The REG_DEAD note
is correct when we look inter-block so maybe it is still 
correct to keep their.  

The question is: what is the correct fix for the longer term ?
is it enough to mark the SMSed block dirty? or do we need 
also to keep the REG_DEAD correct in each basic-block 
separately?

This patch fixes the failure : 

Index: modulo-sched.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/modulo-sched.c,v
retrieving revision 1.19
diff -c -p -r1.19 modulo-sched.c
*** modulo-sched.c      1 Dec 2004 00:33:05 -0000       1.19
--- modulo-sched.c      16 Mar 2005 17:20:59 -0000
*************** sms_schedule (FILE *dump_file)
*** 1109,1114 ****
--- 1109,1116 ----
             scheduling passes doesn't touch it.  */
          if (! flag_resched_modulo_sched)
            g->bb->flags |= BB_DISABLE_SCHEDULE;
+         /* The life-info is not valid any more.  */
+         g->bb->flags |= BB_DIRTY;
   
          generate_reg_moves (ps);
          if (dump_file)


-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-03-16 22:49 -------
There are now two separate bugs being discussed in this PR.
                                                                                
The first bug is an ICE in schedule_insns at sched-rgn.c:2549.  This
still exists in mainline even with Mostafa's patch from comment 13.
I now see this ICE when compiling all but three of the tests in SPEC
CPU2000 on powerpc64-linux with "-O2 -fmodulo-sched" and with either
-m32 or -m64.  All of the test cases mentioned in the original bug
description also still get that ICE with mainline plus the patch when
compiled with -O2 -fmodulo-sched.  They start failing sometime between
20050214 and 20050221, so the bug might have been exposed by the same
patch that exposed the second bug.
                                                                                
The second bug is the internal consistency failure as shown by the
test cases added in comments 3 and 6.  The patch from comment 13
fixes this for both mainline and 4.0-branch.  There is now only one
build failure for SPEC CPU2000 with -O2 -fmodulo-sched: the build of
gap with -m32 gets a segfault, which I'll report separately when I
know more about it.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[mustafa at il dot ibm dot com]

------- Additional Comments From mustafa at il dot ibm dot com  2005-03-17 07:30 -------
I get the ICE in schedule_insns at sched-rgn.c:2549 also in bootstrap with -O2
-fmodulo-sched.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[mustafa at il dot ibm dot com]

------- Additional Comments From mustafa at il dot ibm dot com  2005-03-17 11:53 -------
The following patch should fix the Segmentation fault in gap (from SPEC2000)
mentioned in <a href="#c14">comment 14</a>. This patch is combined with the
patch from <a href="#c13">comment 13</a>. Janis can you try it out.

Index: ddg.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ddg.c,v
retrieving revision 1.11
diff -c -p -r1.11 ddg.c
*** ddg.c	22 Nov 2004 12:23:47 -0000	1.11
--- ddg.c	17 Mar 2005 11:20:37 -0000
*************** create_ddg_dependence (ddg_ptr g, ddg_no
*** 187,192 ****
--- 187,194 ----
        else
  	free (e);
      }
+   else if (t == ANTI_DEP && dt == REG_DEP)
+     free (e);  /* We can fix broken anti register deps using reg-moves.  */
    else
      add_edge_to_ddg (g, e);
  }
Index: modulo-sched.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/modulo-sched.c,v
retrieving revision 1.19
diff -c -p -r1.19 modulo-sched.c
*** modulo-sched.c	1 Dec 2004 00:33:05 -0000	1.19
--- modulo-sched.c	17 Mar 2005 11:20:38 -0000
*************** const_iteration_count (rtx count_reg, ba
*** 339,344 ****
--- 339,348 ----
  {
    rtx insn;
    rtx head, tail;
+ 
+   if (! pre_header)
+     return NULL_RTX;
+ 
    get_block_head_tail (pre_header->index, &head, &tail);
  
    for (insn = tail; insn != PREV_INSN (head); insn = PREV_INSN (insn))
*************** print_node_sched_params (FILE * dump_fil
*** 401,406 ****
--- 405,412 ----
  {
    int i;
  
+   if (! dump_file)
+     return;
    for (i = 0; i < num_nodes; i++)
      {
        node_sched_params_ptr nsp = &node_sched_params[i];
*************** calculate_maxii (ddg_ptr g)
*** 443,456 ****
    return maxii;
  }
  
! 
! /* Given the partial schedule, generate register moves when the length
!    of the register live range is more than ii; the number of moves is
!    determined according to the following equation:
! 		SCHED_TIME (use) - SCHED_TIME (def)   { 1 broken loop-carried
!    nreg_moves = ----------------------------------- - {   dependence.
! 			      ii		      { 0 if not.
!    This handles the modulo-variable-expansions (mve's) needed for the ps.  */
  static void
  generate_reg_moves (partial_schedule_ptr ps)
  {
--- 449,465 ----
    return maxii;
  }
  
! /*
!    Breaking intra-loop register anti-dependences:
!    Each intra-loop register anti-dependence implies a cross-iteration true
!    dependence of distance 1. Therefore, we can remove such false dependencies
!    and figure out if the partial schedule broke them by checking if (for a
!    true-dependence of distance 1): SCHED_TIME (def) < SCHED_TIME (use) and
!    if so generate a register move.   The number of such moves is equal to:
!               SCHED_TIME (use) - SCHED_TIME (def)       { 0 broken
!    nreg_moves = ----------------------------------- + 1 - {   dependecnce.
!                             ii                          { 1 if not.
! */
  static void
  generate_reg_moves (partial_schedule_ptr ps)
  {
*************** generate_reg_moves (partial_schedule_ptr
*** 474,479 ****
--- 483,491 ----
  	  {
  	    int nreg_moves4e = (SCHED_TIME (e->dest) - SCHED_TIME (e->src)) / ii;
  
+             if (e->distance == 1)
+               nreg_moves4e = (SCHED_TIME (e->dest) - SCHED_TIME (e->src) + ii)
/ ii;
+ 
  	    /* If dest precedes src in the schedule of the kernel, then dest
  	       will read before src writes and we can save one reg_copy.  */
  	    if (SCHED_ROW (e->dest) == SCHED_ROW (e->src)
*************** generate_reg_moves (partial_schedule_ptr
*** 497,502 ****
--- 509,517 ----
  	  {
  	    int dest_copy = (SCHED_TIME (e->dest) - SCHED_TIME (e->src)) / ii;
  
+ 	    if (e->distance == 1)
+ 	      dest_copy = (SCHED_TIME (e->dest) - SCHED_TIME (e->src) + ii) / ii;
+ 
  	    if (SCHED_ROW (e->dest) == SCHED_ROW (e->src)
  		&& SCHED_COLUMN (e->dest) < SCHED_COLUMN (e->src))
  	      dest_copy--;
*************** normalize_sched_times (partial_schedule_
*** 539,546 ****
    ddg_ptr g = ps->g;
    int amount = PS_MIN_CYCLE (ps);
    int ii = ps->ii;
! 
!   for (i = 0; i < g->num_nodes; i++)
      {
        ddg_node_ptr u = &g->nodes[i];
        int normalized_time = SCHED_TIME (u) - amount;
--- 554,561 ----
    ddg_ptr g = ps->g;
    int amount = PS_MIN_CYCLE (ps);
    int ii = ps->ii;
!   /* Don't include the closing branch assuming that it is the last node.  */
!   for (i = 0; i < g->num_nodes - 1; i++)
      {
        ddg_node_ptr u = &g->nodes[i];
        int normalized_time = SCHED_TIME (u) - amount;
*************** duplicate_insns_of_cycles (partial_sched
*** 609,615 ****
  	    /* SCHED_STAGE (u_node) >= from_stage == 0.  Generate increasing
  	       number of reg_moves starting with the second occurrence of
  	       u_node, which is generated if its SCHED_STAGE <= to_stage.  */
! 	    i_reg_moves = to_stage - SCHED_STAGE (u_node);
  	    i_reg_moves = MAX (i_reg_moves, 0);
  	    i_reg_moves = MIN (i_reg_moves, SCHED_NREG_MOVES (u_node));
  
--- 624,630 ----
  	    /* SCHED_STAGE (u_node) >= from_stage == 0.  Generate increasing
  	       number of reg_moves starting with the second occurrence of
  	       u_node, which is generated if its SCHED_STAGE <= to_stage.  */
! 	    i_reg_moves = to_stage - SCHED_STAGE (u_node) + 1;
  	    i_reg_moves = MAX (i_reg_moves, 0);
  	    i_reg_moves = MIN (i_reg_moves, SCHED_NREG_MOVES (u_node));
  
*************** sms_schedule (FILE *dump_file)
*** 1109,1114 ****
--- 1124,1131 ----
  	     scheduling passes doesn't touch it.  */
  	  if (! flag_resched_modulo_sched)
  	    g->bb->flags |= BB_DISABLE_SCHEDULE;
+ 	  /* The life-info is not valid any more.  */
+ 	  g->bb->flags |= BB_DIRTY;
  
  	  generate_reg_moves (ps);
  	  if (dump_file)


-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-03-17 21:21 -------
GCC from the 4.0-branch on 20050316 plus the patch from comment 16
successfully builds all of the SPEC CPU2000 tests and those tests run
successfully with small test input.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-20 17:30 -------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01875.html>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-21 18:50 -------
Subject: Bug 20177

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	hagog@gcc.gnu.org	2005-03-21 18:49:31

Modified files:
	gcc            : ChangeLog ddg.c modulo-sched.c passes.c 
Added files:
	gcc/testsuite/gcc.dg: 20050321-1.c 

Log message:
	Fix PR middle-end/20177 and add test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7945&r2=2.7946
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ddg.c.diff?cvsroot=gcc&r1=1.11&r2=1.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/modulo-sched.c.diff?cvsroot=gcc&r1=1.22&r2=1.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&r1=2.74&r2=2.75
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050321-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 13:14 -------
Subject: Bug 20177

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	hagog@gcc.gnu.org	2005-03-30 13:13:40

Modified files:
	gcc            : ChangeLog ddg.c modulo-sched.c passes.c 
Added files:
	gcc/testsuite/gcc.dg: 20050321-1.c 20050330-1.c 

Log message:
	Fix PR middle-end/20177 and two new test cases.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.95&r2=2.7592.2.96
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ddg.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.11&r2=1.11.14.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/modulo-sched.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.72.2.1&r2=2.72.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050321-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050330-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 15:39 -------
Fixed in 4.0.0.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.0


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