--- Comment #16 from steven at gcc dot gnu dot org 2010-07-20 13:55 ---
May be a dup of 43494, based on comment #7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-22 16:14 ---
Note that we usually add the name of the committer to the ChangeLog too, like
so:
2009-06-22 Steven Bosscher <...>
Matthias Klose <...>
etc.
But thanks for handling the patch. Fi
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-22 08:12 ---
Re. Comment #5:
I have no plans to sumbit this patch. But do feel free to foster-parent it ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
--- You are receiving this mail because: ---
You are
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-19 19:57 ---
*** Bug 39210 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-01 23:04 ---
With so many dups, IMHO this ought to be fixed for the releases...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ice-on-valid-code |wrong-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11654
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-13 22:04 ---
I also can't reproduce it (neither on native nor with a cross).
Any local patches? Maybe you can reduce it to a set of simpler configuration
options?
--
steven at gcc dot gnu dot org changed:
--- Comment #8 from steven at gcc dot gnu dot org 2008-01-30 09:10 ---
How did you configure gcc (i.e. command line)? What is the output if you
compile with -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- You are receiving this mail because: ---
You reported
--- Comment #30 from steven at gcc dot gnu dot org 2008-01-12 00:25 ---
After playing with dbgcounts to see what happens, I indeed found the same as
what Eric notes in comment #27. The proposed fix makes perfect sense.
I won't be fixing this, I think Eric has already propose
--- Comment #26 from steven at gcc dot gnu dot org 2008-01-10 23:58 ---
Mark, wrt. the release, I recommend this PR shouldn't be a blocker. The
problem is old and is currently latent on the trunk, where it is only exposed
with non-default options (-fno-inline-small-func
--- Comment #25 from steven at gcc dot gnu dot org 2008-01-10 23:44 ---
So this has been failing since at least GCC 3.4. And I see nothing in the
identified patch that is related to how CSE handles its values, so I suspect
this bug exists in older compilers as well (just needs another
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-10 22:18 ---
Created an attachment (id=14916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14916&action=view)
new test case that fails before the tree-ssa merge
I made a new test case out of the .final_cleanup du
--- Comment #21 from steven at gcc dot gnu dot org 2008-01-09 22:46 ---
at cse.c:5418:
elt = insert (dest, sets[i].src_elt,
sets[i].dest_hash, GET_MODE (dest));
dest = (reg:DI 66 [ type.0+-4 ])
sets[i].src_elt->exp = (sign_extend:DI (reg:SI 72 [ t
--- Comment #20 from steven at gcc dot gnu dot org 2008-01-09 19:09 ---
I still haven't been able to reproduce it with a cross and with the original
test case. I'll try the reduced test case. Wish me luck. ;)
--
steven at gcc dot gnu dot org changed:
What
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #17 from steven at gcc dot gnu dot org 2008-01-08 16:14 ---
Does anyone know how to reproduce this with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- You are receiving this mail because: ---
You are on the CC list for the bug, or
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2007-04-30 11:52:08 |2008-01-07 17:40
--- Comment #6 from steven at gcc dot gnu dot org 2007-12-27 15:28 ---
Actually, that df failure was due to a local patch. With a clean tree, a cross
from cygwin to alpha does not ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- You are receiving this mail
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-27 12:59 ---
Currently breaks with a df-verify error with a cross from i686-cygwin to
alpha-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- You are receiving this mail because: ---
You reported
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 23:31 ---
xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html
I was wrong to object to this patch -- there really doesn't seem to be any
other way. It's funny, on the one hand we complain about the code
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 20:34 ---
Martin, is this a bug you can still reproduce with the current SVN trunk? If
so, could you provide a backtrace from gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
--- You are receiving this mail
--- Comment #3 from steven at gcc dot gnu dot org 2007-12-18 20:33 ---
Martin, is this a bug you can still reproduce with the current SVN trunk? If
so, could you provide a backtrace from gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
--- You are receiving this mail
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 20:29 ---
See http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01406.html for recent test
suite results. The first three failures are gone, as observed by Andreas too.
The largefile.c failures still exist. But as Andrew
--- Comment #8 from steven at gcc dot gnu dot org 2007-12-16 23:20 ---
Waiting for DR -> SUSPENDED.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #12 from steven at gcc dot gnu dot org 2007-12-16 23:19 ---
If we are waiting for a DR, this PR should be SUSPENDED, not WAITING.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2007-12-05 22:29 ---
What does the full cse1 dump look like at that point (don't forget to call
fflush(dump_file) from gdb ;-) Is this reproducible with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #8 from steven at gcc dot gnu dot org 2007-11-26 20:07 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #3 from steven at gcc dot gnu dot org 2007-11-26 14:14 ---
flow.c is gone, so if this bug is still around in GCC 4.3, it's somewhere else
now. For released versions of GCC this won't be fixed.
If you still see a problem, please file a new bug report about it.
-
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-26 14:12 ---
No test case, no progress. If this problem still exists, we need more than a
pointer to a build log to investigate the problem.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from steven at gcc dot gnu dot org 2007-11-14 10:00 ---
Is this still a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30088
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
To
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-10 16:40 ---
Patch is waiting for approval of the C++ bits.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-05 21:38 ---
It seems to me that a recursive function can never be safely treated as
const/pure. In fact, any function in an SCC in the call graph could result in
an endless loop and is therefore not const/pure. I'm assuming
--- Comment #3 from steven at gcc dot gnu dot org 2007-10-21 10:00 ---
The way for you to narrow down the bug is this:
1. Compile with -daAP
2. Look in the .s file which instruction references the missing label. There
should be a LABEL_REF with a number.
3. Grep for "code_label.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||33356
nThis||
http
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|steven at gcc dot gnu dot |
|org |
http
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-11 21:51 ---
There doesn't seem to be another way to get this to work, than the proposed way
with extra basic blocks. The things I've tried either break gcc, or gdb, or
debug info. Unassigning.
--
steven at gcc d
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-30 12:01 ---
There are at least 2 issues here:
1) We just lose the locus of the goto statements when we lower GIMPLE and when
we jump across forwarded blocks.
2) When we don't lose the locus in GIMPLE, we lose it in cfge
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #8 from steven at gcc dot gnu dot org 2006-11-18 01:27 ---
Shouldn't this be fixed by Roger Sayle's recent fold-const.c patch?
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Summary|gcj should generate N_MAIN |gcc should allow gcj and
|stab or DW_AT_entry_point
--- Comment #19 from steven at gcc dot gnu dot org 2006-10-14 14:17 ---
Someone should make gdb understand the DW_AT_calling_convention attribute.
This is the bit necessary to make it work for Fortran. I considered stealing a
bit on FUNCTION_DECL to mark it as the main program but it
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-25 15:04 ---
Either show that it is a regression, or dont put the regression marker in the
subject.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-08-02 21:10 ---
Happens when we are in find_if_case_1, where we call:
delete_basic_block (then_bb);
The basic block we try to remove is this one:
;; basic block 5, loop depth 1, count 0
;; prev block 9, next block 6
;; pred
--- Comment #7 from steven at gcc dot gnu dot org 2006-08-02 20:52 ---
;; Insn is not within a basic block
(code_label 48 47 49 11 "" [3 uses])
;; Insn is not within a basic block
(jump_insn 49 48 50 (addr_diff_vec:DI (label_ref:DI 48)
[
(label_
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2006-08-02 19:03 ---
There are a million reasons why labels can disappear in GCC. This happens
because GCC deletes or keeps labels based on ref counting (LABEL_NUSES and
friends) and this is just too fragile.
The way for you to narrow
--- Comment #10 from steven at gcc dot gnu dot org 2006-08-01 05:51 ---
Why is this a P1 regression? ia-64 is not a primary platform.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-29 10:57 ---
Please stop adding test cases!!! :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-29 10:32 ---
Zdenek's patch also can't be responsible for this. He probably also just
uncovered latent bugs.
Instead of pointing at random patches, it would be much more helpful to analyze
what is going wrong. For th
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|steven at gcc dot gnu dot |
|org |
http
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-15 22:58 ---
Probably latent on mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28243
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-09 10:29 ---
FX, are you working on this problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To
--- Comment #14 from steven at gcc dot gnu dot org 2006-06-05 10:44 ---
The failures in 3.4 and later are in fold_const, so the gen_lowpart problem is
now avoided by, well, ICEing earlier :)
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from steven at gcc dot gnu dot org 2006-06-05 10:41 ---
Unassigning rth, since he's obviously not actually interested in fixing this.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #13 from steven at gcc dot gnu dot org 2006-02-27 21:13 ---
'tis done.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #12 from steven at gcc dot gnu dot org 2006-02-27 21:12 ---
Subject: Bug 25196
Author: steven
Date: Mon Feb 27 21:12:54 2006
New Revision: 111490
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111490
Log:
Backport from mainline and the GCC 4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[3.4/4.0/4.1/4.2 Regression]|[3.4/4.0/4.1/4.2 Regression]
|ICE on testcase with
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-01-10 20:36:18 |2006-01-10 23:44:58
date
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-10 23:44 ---
Fair enough. I think it's highly unlikely that anyone would care enough about
i386 to worry about fixing this, but you never know.
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #15 from steven at gcc dot gnu dot org 2006-01-10 23:36 ---
Then I am quite sure that the difference comes from using "repnz; scasb" in GCC
3.2 vs. calling strlen in GCC 3.3 on i486. For GCC 3.2, the code for i386 and
i486 are pretty much equivalent (the only dif
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-10 23:04 ---
Created an attachment (id=10615)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10615&action=view)
gcc 3.2 vs. gcc 4.0 .s output, march=i686
For the sake of completeness, also a diff between GCC 3.2
--- Comment #12 from steven at gcc dot gnu dot org 2006-01-10 23:02 ---
For the record, it is a known problem that x86 32 bits hosts and x86_64 hosts
sometimes produce different code, even with the same -march options. We may be
seeing one such case here, eventhough that is quite
--- Comment #11 from steven at gcc dot gnu dot org 2006-01-10 23:01 ---
Created an attachment (id=10614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10614&action=view)
gcc 3.2 vs. gcc 3.3 .s output, march=i686
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-10 23:00 ---
Created an attachment (id=10613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10613&action=view)
gcc 3.2 vs. gcc 3.3 .s output, march=i586
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #9 from steven at gcc dot gnu dot org 2006-01-10 23:00 ---
Created an attachment (id=10612)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10612&action=view)
gcc 3.2 vs. gcc 3.3 .s output, march=i486
All .s files created on AMD64, compiler options -m32 -S -O2 -
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-10 22:58 ---
Unfortunately you're not showing your full command line, so I can only guess
what platform your host is and for what target you are compiling. I will
attach diffs between GCC 3.2 and GCC 3.3-hammer for i[456]86
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 21:32 ---
Since GCC 3.2 also has this problem, contrary to what the reporter claims, I am
not sure if we should keep this marked as a regression. Obviously it is a
missed optimization, so the bug report is valid in that sense
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-10 21:27 ---
FWIW, the peephole that we trigger is this one, which has been around since
forever (since rth's ia32 backend rewrite from the previous century...):
;; Don't compare memory with zero, load and use a te
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ra |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
--- You are
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-10 20:57 ---
On the trunk, we have the following situation in the .csa RTL dump (on AMD64
-m32 -march=i686):
;; Start of basic block 5, registers live:
4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame]
(code_label:HI 38 37 39 5 2 "
--- Comment #3 from steven at gcc dot gnu dot org 2006-01-10 20:36 ---
GCC 4.2 (trunk) produces this kind of redundant loads:
...
movl-20(%ebp), %eax
testl %eax, %eax
je .L10
movl-20(%ebp), %eax
movl%eax, (%esp
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-21 15:46 ---
Fixed on the trunk and on the GCC 4.1 branch.
See http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01177.html and
http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01178.html (I used the wrong bug
number in the commit >:-/)
Will
--- Comment #14 from steven at gcc dot gnu dot org 2005-12-20 16:11 ---
The patch proposed in bug 25196 comment #8 indeed makes the test case from
comment #6 in this PR work (at least, it stops it from segfaulting).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- You
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-20 15:58 ---
Gross. According to a comment in postreload.c:move2add_note_store(), we can
have pushes without REG_INC notes:
/* Some targets do argument pushes without adding REG_INC notes. */
So we need to go look for those
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-20 14:59 ---
Does not fail with trunk or the head of the gcc 4.1 branch. But it does fail
with gcc 4.0.2. I'm going to try it with the head of the gcc 4.0 branch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-20 10:48 ---
Almost certainly a dup of PR25196
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To
--- Comment #37 from steven at gcc dot gnu dot org 2005-12-19 12:36 ---
That would be a different bug, and the fix would still be to not have a
no-conflict block to begin with.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 17:15 ---
rth assigned this to himself:
http://gcc.gnu.org/ml/gcc-bugs/2005-11/msg02843.html
A progress report would be nice ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
--- You are receiving this mail
--- Comment #30 from steven at gcc dot gnu dot org 2005-12-16 22:25 ---
Should be fixed on the trunk.
I guess the patch could be backported to all active branches, the bug is latent
but present in all GCCs releases since 2.early.
--
steven at gcc dot gnu dot org changed
--- Comment #29 from steven at gcc dot gnu dot org 2005-12-16 22:19 ---
Subject: Bug 23837
Author: steven
Date: Fri Dec 16 22:19:09 2005
New Revision: 108690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108690
Log:
PR rtl-optimization/23837
*
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc
--- Comment #11 from steven at gcc dot gnu dot org 2005-12-15 06:50 ---
If nobody is going to fix gcse2, the right thing to do is to not set
flag_gcse_after_reload for optimize >= 3 in opts.c:
Index: opts.c
===
--- opt
--- Comment #27 from steven at gcc dot gnu dot org 2005-12-15 06:42 ---
accept while testing a patch...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from steven at gcc dot gnu dot org 2005-12-15 00:54 ---
Needless to say really, but the patchlet in comment #25 is inverted...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
--- You are receiving this mail because: ---
You reported the bug, or are
--- Comment #25 from steven at gcc dot gnu dot org 2005-12-15 00:52 ---
Smarter folks than me (iant ;-) suggest that "a multi-word rotate will normally
need all the input bits when setting any of the output bits", so the entire
no-conflict thing doesn't make sense here.
--- Comment #24 from steven at gcc dot gnu dot org 2005-12-15 00:09 ---
I think we can blame combine for this bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2005-12-15 00:00 ---
lreg decides to do this:
;; Register 95 in 25.
;; Register 97 in 28.
;; Register 99 in 22.
;; Register 102 in 21.
;; Register 104 in 25.
;; Register 111 in 28.
;; Register 112 in 19.
;; Register 113 in 28.
and
--- Comment #20 from steven at gcc dot gnu dot org 2005-12-12 22:14 ---
Created an attachment (id=10463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10463&action=view)
a full set of debugging dumps
Re. comment #16, sorry, I didn't read it until after going
--- Comment #19 from steven at gcc dot gnu dot org 2005-12-12 22:03 ---
The dumps before and after scheduling look OK to me.
There are three groups of instructions for libcalls:
1) 19-14-18-20
inputs: regs 95, 99, and 102 (all of them for x)
result: reg 97
clobbers: nothing
2
--- Comment #18 from steven at gcc dot gnu dot org 2005-12-12 21:38 ---
Created an attachment (id=10462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10462&action=view)
Instruction stream (stripped) after scheduling
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #17 from steven at gcc dot gnu dot org 2005-12-12 21:38 ---
Created an attachment (id=10461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10461&action=view)
Instruction stream (stripped) before scheduling
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #15 from steven at gcc dot gnu dot org 2005-12-12 20:19 ---
I can reproduce this on hppa2.0-suse-linux-gnu with the "4.2-20051210"
snapshot.
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-09-20 19:06:43 |2005-11-06 17:47
1 - 100 of 132 matches
Mail list logo
