--- Comment #1 from steven at gcc dot gnu dot org 2009-08-10 21:33 ---
Can you attach the preprocessed source, so that we can try to reproduce this
without building a complete cross-toolchain?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-04 22:56 ---
For the record, Jakub has apparently dropped this bug from his list to put this
bug back into unassigned state.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--- Comment #5 from steven at gcc dot gnu dot org 2005-11-04 22:58 ---
Is anyone going to look into this? Is there a smaller test case at least?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-04 23:17 ---
In the .life1 dump we have:
(insn 41 38 42 2 (set (reg:V2SI 79 [ D.2609 ])
(subreg:V2SI (reg:V8QI 76) 0)) 998 {*movv2si_internal_rex64
(insn_list:REG_DEP_TRUE 32 (nil))
(expr_list:REG_DEAD
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-04 23:26 ---
According to rth on IRC this is indeed absolutely wrong.
So it looks like we may have a combine bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22432
--- Comment #11 from steven at gcc dot gnu dot org 2005-11-05 10:31 ---
This is probably a dup of Bug 22509, which has a patch.
Can someone check if this bug is fixed by the patch from Bug 22509?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-05 10:48 ---
This doesn't fail for me with the test case from comment #6... :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #11 from steven at gcc dot gnu dot org 2005-11-05 16:34 ---
Comment #5 is not helpful. Why is this a loop.c bug, you think? In my
backtrace we bail out from regmove. It would be far more helpful if you'd add
some explanation for why you think this is a loop.
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-05 16:55 ---
Breakpoint 4, emit_move_insn (x=0x2a95a69320, y=0x2a9594c820) at expr.c:3140
3140 enum machine_mode mode = GET_MODE (x);
(gdb) p debug_rtx(x)
(reg:DI 68)
$10 = void
(gdb) p debug_rtx(y)
(const:DI (plus:DI
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-05 16:59 ---
ICE on a primary platform, in a popular package.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-06 01:20 ---
Oh well, I'll try and fix this...
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-06 11:50 ---
Folks, what's up with this bug? Is it HPPA-only now? Can someone comment on
the status of this bug please?
--
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
--- Comment #14 from steven at gcc dot gnu dot org 2005-11-07 17:19 ---
As an interesting data point: Intel's ICC 8.0 does what GCC 3.3 and earlier do,
but it seems that ICC 9.0 follow GCC 3.4 and later...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29 ---
We get to "check_substring:" in match_varspec:
PROGRAM P
IMPLICIT CHARACTER*8 (Y)
YLOCAL='A'
YBTABLE=YLOCAL(1:2)
END
check_substring:
if (primary->
--- Comment #27 from steven at gcc dot gnu dot org 2005-11-08 00:18 ---
On AMD64, revision 106596M (the M is for a local loop-invariant.c
patch, nothing special), compiler built with --enable-checking=release:
at -O1:
tree operand scan : 1.50 (10%) usr 0.09 (17%) sys 1.62
--- Comment #5 from steven at gcc dot gnu dot org 2005-11-08 07:44 ---
Created an attachment (id=10170)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10170&action=view)
merge patch from the killloop-branch
With this patch applied and -fmove-loop-invariants enabled by def
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-08 13:45 ---
The patch from comment #7 is wrong.
The proper fix is already on the killloop-branch. You could try my patch for
PR 24408, which should depend on this one.
--
steven at gcc dot gnu dot org changed
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-08 20:36 ---
I found an extra problem with loop-invariant.c, which is that it would move
expressions out of loops with calls, even if the expressions used call
clobbered hard registers. I'm testing a fix for this bug now
c dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
GCC target triplet: ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-09 20:12 ---
Created an attachment (id=10197)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10197&action=view)
loop2_init dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-09 20:12 ---
Created an attachment (id=10198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10198&action=view)
loop2_invariant dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-09 23:45 ---
Actually, flow.c does get it right.
>From t.C.26.life1 (at -O1 -fno-move-loop-invariants):
;; Start of basic block 3, registers live: 0 [ap] 1 [r1] 12 [r12] 15 [r15] 16
[r16] 328 [sfp]
341 344
(code_label/s 62
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|minor
Keywords||patch
http
--
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 #11 from steven at gcc dot gnu dot org 2005-11-11 19:34 ---
Subject: Bug 24265
Author: steven
Date: Fri Nov 11 19:34:39 2005
New Revision: 106795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106795
Log:
PR 24265
* loop-invariant.c (may_assi
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-11 19:39 ---
Fixed on mainline. The bug is also on the GCC 4.0 branch, but I am not going
to backport the patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-13 01:38 ---
Doesn't happen anymore on current mainline.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-13 01:41 ---
IIUC, this is one of the things that's being worked on in the dataflow-branch.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-13 01:43 ---
This hasn't been addressed yet in r106784.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-13 12:24 ---
*** This bug has been marked as a duplicate of 20839 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-13 12:24 ---
*** Bug 24806 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-13 13:56 ---
Created an attachment (id=10230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10230&action=view)
patch
I can't think of better wording for the diagnostic. Some help there would be
appreciated.
--- Comment #4 from steven at gcc dot gnu dot org 2005-11-13 16:17 ---
What happens here is just copy propagation by DOM and VRP for "conditional
copies", e.g. with "if (a==b) ..." we can record b as a copy of a, or a as a
copy of b. In this case, copy propagation
--- Comment #20 from steven at gcc dot gnu dot org 2005-11-14 00:28 ---
Is this still a problem? The SPEC graph for mgrid on PPC has moved up lately:
http://www.suse.de/~gcctest/SPEC/CFP/sb-huckleberry2-head-64/172_mgrid_big.png
--
steven at gcc dot gnu dot org changed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||fche at redhat dot com
Status|UNCONFIRMED
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-14 10:32 ---
It would be more interesting to measure than think ;-)
My experience is that when it is in Briggs' test suite, it usually also happens
in actually useful code. But, only the numbers will tell :-)
Zdenek is
--- Comment #22 from steven at gcc dot gnu dot org 2005-11-14 10:36 ---
Yes, mesa is down. But is that related to this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-14 22:47 ---
The dataflow-branch is also failing for this test case. There is nothing in
the df object that makes loop-invariant.c think that the insns setting those
EH_RETURN_DATA_REGNO regs are not loop invariant
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:20 ---
It would be useful to to either have separate bugs for these issues, or to list
them all in the audit trail of this bug. Without more information, this bug
does not contain much information, it's more like a
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-15 12:51 ---
As a work-around, configure with --disable-libmudflap, you don't need that
library anyway, it is an instrumentation library for memory access violations
for C and C++, so you don't need it for gfortran.
-
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:53 ---
Note that we would still like to know what target you are configuring for. If
you can copy-and-paste the first, say, 10 lines of output from your configure,
that would be most helpful.
--
steven at gcc dot gnu
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-15 23:15 ---
Show me one compiler that catches this. HP doesn't, and Intel doesn't.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-15 23:58 ---
There is no way we can diagnose this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-16 08:52 ---
Re. comment #9
GCSE store motion is very broken, and it's really been like that for a long
time. And it doesn't really do much, either, when you turn it on. Sadly we
have nothing to replace it right
--- Comment #33 from steven at gcc dot gnu dot org 2005-11-16 09:42 ---
Zdenek, any news about your patch from comment #30?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-16 14:12 ---
Is this bug going anywhere???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-18 16:17 ---
Let's make it WONTFIX then. Even the theoretical possibility of fixing this
probably doesn't exist. Catching this kind of thing is a Very Hard Problem,
it's more something for a static checker or
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from steven at gcc dot gnu dot org 2005-11-18 23:35 ---
I can't reproduce this with r107187.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
--- Comment #9 from steven at gcc dot gnu dot org 2005-11-18 23:37 ---
This does in no way block the removal of loop.c. Rather, the (now latent
again) bug would disappear with loop.c if/when we nuke it.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from steven at gcc dot gnu dot org 2005-11-22 07:33 ---
Well then...
Mine.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #21 from steven at gcc dot gnu dot org 2005-12-01 20:17 ---
For Bug 21803 we could use similar infrastructure to what is proposed for this
bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
mization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243
--- Comment #1 from steven at gcc dot gnu dot org 2005-12-03 14:22 ---
I should have said, this is at "-O1 -fthread-jumps". I guess VRP catches this
at -O2 and better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243
--- Comment #2 from steven at gcc dot gnu dot org 2005-12-03 14:37 ---
Actually VRP doesn't catch it.
Do:
-if (e[i] == 16)
+if (e[i] == 16)
so that store-CCP doesn't load e[0] anymore to find that it is 16. With that,
the .vrp dump at -O2 looks like this:
baz (r
--- Comment #3 from steven at gcc dot gnu dot org 2005-12-03 15:46 ---
With a minor hack, we optimize the test case in dom3:
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 107822)
+++ tree-ssa-dom.c
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||gerald at pfeifer dot com
Status|UNCONFIRMED
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-03 17:46 ---
Actually, it's more related to Bug 21488. What happens is that we record a
value for the left hand side of a single-argument PHI node (i.e. for
"rhs=PHI(lhs)" we record an equivalence rhs==lhs), bu
--- Comment #1 from steven at gcc dot gnu dot org 2005-12-04 17:14 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-05 18:05 ---
Created an attachment (id=10410)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10410&action=view)
follow SSA_NAME_VALUE deep
Hmmwell, the attached patch does bootstrap on i686,ia64, and x86-64, and it
--- Comment #17 from steven at gcc dot gnu dot org 2005-12-09 14:26 ---
Created an attachment (id=10445)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10445&action=view)
Smaller test case
--
steven at gcc dot gnu dot org changed:
What|
--- Comment #18 from steven at gcc dot gnu dot org 2005-12-09 15:37 ---
>From the diff between the old-loop and gcse1 dumps, this looks like a loop.c
strength reduction bug. Indeed, -fno-strength-reduce makes the miscompilation
go away for me.
--
http://gcc.gnu.org/bugzi
--- Comment #19 from steven at gcc dot gnu dot org 2005-12-10 00:31 ---
This is beyond my RTL fu.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
--- 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?id=23837
--- 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?id=23837
--- 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 #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 #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 #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 #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
--- 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 #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 #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 #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
*
--- Comment #3 from steven at gcc dot gnu dot org 2005-12-16 22:21 ---
Sorry for this. I had to edit my patch that caused this problem, and I forgot
to bootstrap it on a target with delay slots :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25457
--- 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 #20 from steven at gcc dot gnu dot org 2005-12-16 22:46 ---
Review mail was here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00121.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-16 23:58 ---
Re. comment #3, I can reproduce the bug with -fno-gcse-lm too, so this may be
unrelated to load motion. I also tried with -O -fgcse and I'm seeing the bug
then, too. Finally, I tried with CPROP1, CPROP2 and
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-17 11:27 ---
Looking into this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-17 11:31 ---
Also seen on powerpc
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC host
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-17 15:09 ---
Created an attachment (id=10519)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10519&action=view)
Smaller test case
Fails for me when compiled with:
"g++ -O -fgcse t.C -fno-exceptions -fno-tree-do
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-17 15:14 ---
It looks like we're missing a memory modification. Yes, making this a load PRE
problem after all, despite it failing for me even with -fno-gcse-lm, but oh
well.
I have these expressions in the table:
Expre
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-17 18:23 ---
Breakpoint 7, compute_transp (x=0x4021557c, indx=0, bmap=0x894e1b8, set_p=0) at
gcse.c:2500
2500rtx list_entry = canon_modify_mem_list[bb_index];
(gdb) p debug_rtx(x)
(mem/s/j:SI (plus:SI (reg
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 00:49 ---
At -O1 (i.e. for my test case) CSE1 turns this...
(insn 24 22 25 0 (parallel [
(set (reg/f:SI 67)
(plus:SI (reg/f:SI 20 frame)
(const_int -16 [0xfff0
--- Comment #11 from steven at gcc dot gnu dot org 2005-12-18 01:38 ---
Punt for now.
http://gcc.gnu.org/ml/gcc/2005-12/msg00504.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2005-12-18 14:30 ---
This bug was for mgrid, but now we're stuck on a reported mesa performance drop
that may or may not be related to this PR. I suggest that if the mesa drop is
still there, a new bug report should be opened f
--- Comment #3 from steven at gcc dot gnu dot org 2005-12-18 14:32 ---
ping!
There are too many reports about SPEC performance drops that stay in WAITING
for too long. That is not helpful. Uttam, please investigate this bug, you
cannot just drop a bug report about SPEC performance
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-18 14:36 ---
For historic reference, once this is on the 4.1 branch too.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-18 14:53 ---
fixeth yet
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-18 15:42 ---
What is one supposed to do with this bug report?
First, it looks from the command lines in the report that the problematic
compiler is GCC 3.3. But the report is about gcc 4.1.0.
Second, I can't reproduc
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-18 15:45 ---
Unable to reproduce with GCC 4.1 without further feedback. Apparently already
fixed or made latent on GCC 4.2. The dumps in comment #1 could use some
comment so that people reading this bug report don't ha
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 15:45 ---
Unable to reproduce with GCC 4.1 without further feedback. Apparently already
fixed or made latent on GCC 4.2. The dumps in comment #1 could use some
comment so that people reading this bug report don't ha
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 15:51 ---
Kazu assigned this to himself on December 17, see
http://gcc.gnu.org/ml/gcc-bugs/2005-12/msg01787.html
Folks, please add a comment when you assign a bug to yourself. That way, it's
easier to see which bugs hav
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-18 15:55 ---
Paolo, are you going to ask for approval for GCC 4.1 too?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 16:04 ---
comment #6 says "invalid code". So is this an ICE on valid, or _invalid_ code?
Anyway,
Starting program: /abuild/stevenb/build/gcc/cc1plus t.C
A::A()
Breakpoint 4, expand_member_init (name=0x401c9958)
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-18 16:36 ---
Giovanni, you never assigned this bug to yourself as far as I can tell, but
could you give this bug a quick look anyway, or otherwise unassign yourself
from this bug? Thanks.
--
http://gcc.gnu.org/bugzilla
--- Comment #45 from steven at gcc dot gnu dot org 2005-12-18 16:40 ---
Alexandre, what is up with this bug? It's a gcc 4.1 regression assigned to
you, could you please at least say whether you're working on this or not?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_
401 - 500 of 3051 matches
Mail list logo
