--- Comment #17 from abel at ispras dot ru 2008-09-08 07:19 ---
(In reply to comment #16)
> Could you explain why max_issue() should do anything
> when more_issue <= 0? I'd have expected it to early-out.
But the whole point of the patch is that we _can_ actually issue m
--- Comment #14 from abel at ispras dot ru 2008-09-05 10:33 ---
Created an attachment (id=16231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16231&action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #13 from abel at ispras dot ru 2008-09-05 10:32 ---
(In reply to comment #12)
> I think it's reasonable to disable the assert with a comment for now and
> file a separate bugreport for the targets who lie about their issue rate.
Ok, with the below patch my failin
--- Comment #11 from abel at ispras dot ru 2008-09-05 09:16 ---
I was unable to trigger the assert on the given testcase even with the
cross-compiler configured exactly like the one in the bug report. However, I
was able to reproduce the ICE on a longer plain C test case.
The assert
--- Comment #3 from abel at ispras dot ru 2008-09-04 14:34 ---
This does not fail on a cross for us with 139918.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #2 from abel at ispras dot ru 2008-09-04 12:06 ---
> Andrey, this is likely due to the selective scheduler merge. Can you
> investigate or delegate?
We couldn't reproduce this with a cross from x86_64. Also, Adam Nemet fixed
the problem with MIPS/sel-sched boot
--- Comment #1 from abel at ispras dot ru 2006-02-17 14:08 ---
I've see the same ICE on ia64 with rev. 76 and
gcc.c-torture/compile/930217-1.c. The backtrace is as follows:
(gdb) bt
#0 fancy_abort (file=0x40a4d260
"/home/bonzo/develop/loop/trunk/gcc/tree-ssa-
