https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12955
--- Comment #15 from Steven Bosscher ---
> cc-ing Geoffrey Keating from that thread
Eric, can you please stop adding people from the past to CC lists?
I'm sure you mean well, but it's not always appreciated.
Geoff hasn't been involved in GCC wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151
--- Comment #8 from Steven Bosscher 2013-02-04
17:59:22 UTC ---
(In reply to comment #7)
> Created attachment 29350 [details]
> gcc48-pr56151.patch
>
> Untested patch for the peephole mentioned in previous comment.
I don't think a ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #17 from Steven Bosscher 2013-02-08
22:51:26 UTC ---
(In reply to comment #16)
> I find myself in agreement with Richi in c#12.
Does that also apply to the "Thus, let's deprecate anything but dwarf
in 4.8" part? Otherwise, w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
Steven Bosscher changed:
What|Removed |Added
Keywords||ice-checking
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
--- Comment #6 from Steven Bosscher 2013-02-12
00:14:47 UTC ---
In gcc 4.7.2, reload resolved this with a pair of moves.
>From the .197r.ira and 198r.reload dumps, with the asm_operands
split out and the insns before the asm condensed, f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
--- Comment #10 from Steven Bosscher 2013-02-12
18:12:00 UTC ---
Vlad, could you please explain a bit how you figured out this issue
so quickly? (I mean, apart from experience, of course.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56246
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
--- Comment #12 from Steven Bosscher 2013-02-14
17:10:02 UTC ---
A bit more clear with insn 195 added:
195: flags:CC=cmp(r124:DI,r235:DI)
197: r116:DI={(gtu(flags:CC,0))?r125:DI:r233:DI}
199: {r110:DI=r110:DI+0x1;clobber flags:CC;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
Steven Bosscher changed:
What|Removed |Added
Keywords||missed-optimization
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
--- Comment #20 from Steven Bosscher 2013-02-14
22:17:23 UTC ---
(In reply to comment #12)
> --- by-val-O3.s.orig2013-02-14 18:06:56.0 +0100
> +++ by-val-O3.s 2013-02-14 18:07:23.0 +0100
> @@ -357,9 +357,8 @@
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56330
Steven Bosscher changed:
What|Removed |Added
Summary|[4.8 Regression] ICE: |ICE: verify_gimple failed:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339
--- Comment #2 from Steven Bosscher 2013-02-15
10:00:13 UTC ---
The "unbreakable" insns 12 "xmm2:DF=xmm2:DF+xmm0:DF" is created by regmove.
.ce3 dump:
2: r64:DF=xmm0:DF
8: r66:DF=xmm2:DF
12: r67:DF=r66:DF+r64:DF
17: xmm0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339
--- Comment #3 from Steven Bosscher 2013-02-15
10:17:19 UTC ---
Before regmove, both input operands die in insn 12:
12: r67:DF=r66:DF+r64:DF
REG_DEAD r66:DF
REG_DEAD r64:DF
and because reg classes haven't been set up, r6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339
--- Comment #4 from Steven Bosscher 2013-02-15
10:20:52 UTC ---
Perhaps for regmove IRA classes should be set up unconditionally:
Index: regmove.c
===
--- regmove.c (revi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55163
--- Comment #1 from Steven Bosscher 2013-02-15
10:32:22 UTC ---
What happens with GCC 4.7 if you configure with --enable-build-with-cxx ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56405
Steven Bosscher changed:
What|Removed |Added
Keywords||ice-on-valid-code, patch
||steven at gcc dot gnu.org
Resolution|FIXED |
--- Comment #13 from Steven Bosscher 2013-02-21
10:29:25 UTC ---
The fix for this PR is wrong.
Nothing even trying to look at the CFG after freeing it, so the looks at
BLOCK_FOR_INSN in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242
Steven Bosscher changed:
What|Removed |Added
Depends on||56131
--- Comment #12 from St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55996
--- Comment #4 from Steven Bosscher 2013-02-21
12:36:46 UTC ---
Patch to make DF-scan dumps cleaner and speed up complete re-scanning
and deferred rescanning:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00961.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131
--- Comment #16 from Steven Bosscher 2013-02-22
16:33:58 UTC ---
(In reply to comment #14)
Yes, iff the CFG hasn't been freed, looking at BLOCK_FOR_INSN is of
course OK. I was referring to the situation after freeing the CFG.
Adding t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000
Steven Bosscher changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000
--- Comment #10 from Steven Bosscher 2013-02-22
23:42:03 UTC ---
(In reply to comment #9)
> 4.8 r196182 with "--param early-inlining-insns=2" (2 x the default value):
"--param early-inlining-insns=22"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
Steven Bosscher changed:
What|Removed |Added
Keywords||ra
--- Comment #14 from Steve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
Steven Bosscher changed:
What|Removed |Added
Keywords||missed-optimization
||2013-02-26
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Steven Bosscher 2013-02-26
18:26:40 UTC ---
Re. patch:
- Why change the sort order?
- Why qsort the whole
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460
--- Comment #3 from Steven Bosscher 2013-02-26
22:57:02 UTC ---
(In reply to comment #2)
> - Why qsort the whole array, instead of e.g. memmove'ing the bits
Ah, oops. qsort can't be used in libgcc, the target may not provide
a qsort i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460
Steven Bosscher changed:
What|Removed |Added
CC|steven at gcc dot gnu.org |
AssignedTo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460
Steven Bosscher changed:
What|Removed |Added
Status|NEW |ASSIGNED
-10-30 00:00:00 |2013-02-28
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #9 from Steven Bosscher 2013-02-28
22:49:16 UTC ---
I first tried at -O0, only to run into even worse compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #10 from Steven Bosscher 2013-02-28
23:58:38 UTC ---
Created attachment 29557
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29557
Collected hacks to make the test case compile in reasonable time with -O0
Patch does 2 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
Steven Bosscher changed:
What|Removed |Added
Keywords||compile-time-hog,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #12 from Steven Bosscher 2013-03-01
07:50:43 UTC ---
Last night's compilation at -O1 with my hacks applied finished after
a whopping >6 hours. Top compile time consumers:
early inlining heuristics: 12409.92 (55%) usr
integ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #13 from Steven Bosscher 2013-03-01
07:52:41 UTC ---
For reference, my numbers are for GCC 4.8 trunk r196182, configured
with release checking, on x86_64-unknown-linux-gnu, on AMD Opteron
Processor 8354 at 2200MHz.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #16 from Steven Bosscher 2013-03-01
14:35:20 UTC ---
(In reply to comment #15)
> > - Queue up to-be-removed EH regions, instead of removing them one-by-one.
> > Removing them one at a time results in walking the list of EH re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #19 from Steven Bosscher 2013-03-01
19:13:32 UTC ---
(In reply to comment #18)
I thought you had already done that, to handle attribute flatten for
bug 54146 (http://gcc.gnu.org/PR54146#c43). This test case doesn't use
the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #20 from Steven Bosscher 2013-03-01
21:05:00 UTC ---
(In reply to comment #15)
> Trading memory O(number of pseudos) with a large constant factor sounds
> like something waiting for trouble for other testcases ...
FWIW, for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
Steven Bosscher changed:
What|Removed |Added
Keywords||compile-time-hog
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
Steven Bosscher changed:
What|Removed |Added
CC|steven at gcc dot gnu.org |aoliva at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
Steven Bosscher changed:
What|Removed |Added
Summary|[4.8 Regression] More |[4.7/4.8 Regression] More
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
--- Comment #9 from Steven Bosscher 2013-03-03
12:50:32 UTC ---
(In reply to comment #8)
> OT, are you sure the testcase doesn't violate aliasing just about
> everywhere?
At least -Wstrict-aliasing=2 doesn't think so, but it's certainly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343
Steven Bosscher changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #21 from Steven Bosscher 2013-03-05
14:45:32 UTC ---
Author: steven
Date: Tue Mar 5 14:45:23 2013
New Revision: 196464
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196464
Log:
gcc/
PR c++/55135
* except
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #22 from Steven Bosscher 2013-03-05
16:40:40 UTC ---
(In reply to comment #20)
> I have a fix proper for this problem in testing.
Posted for discussion here:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
Steven Bosscher changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
Steven Bosscher changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #10 from S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49319
Steven Bosscher changed:
What|Removed |Added
Summary|[4.7/4.8 regression]|[4.7 regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47270
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||steven at gcc dot gnu.org
--- Comment #5 from Steven Bosscher 2013-03-05
23:45:38 UTC ---
At trunk r196410, the .164t.optimized dump looks like this:
lfsr (long unsigned int number)
{
unsigned char b;
long unsigned int _4;
long unsigned int _5;
_Bool _8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55402
--- Comment #11 from Steven Bosscher 2013-03-06
10:30:20 UTC ---
Maybe the issues in this bug are the same as those for bug 55135.
,
||steven at gcc dot gnu.org
--- Comment #5 from Steven Bosscher 2013-03-06
10:38:08 UTC ---
More var-tracking slowness. Maybe fixed by recent patches, needs triaging.
NB: this is only not marked as a regression because all maintained release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
Steven Bosscher changed:
What|Removed |Added
Summary|gcc 4.3.1 cannot compile|[4.6/4.7/4.8 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47344
--- Comment #7 from Steven Bosscher 2013-03-06
10:51:27 UTC ---
This bug looks like the wrong idea to me. Old is apparently anything
older than the maintained release branches, but many users "in the field"
still use older compilers that c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
Steven Bosscher changed:
What|Removed |Added
Component|middle-end |c
--- Comment #29 from Steven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Steven Bosscher changed:
What|Removed |Added
Status|WAITING |NEW
URL|http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54896
Steven Bosscher changed:
What|Removed |Added
Summary|Some optimization slowness |optimization slowness on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
Steven Bosscher changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org |
Blocks|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47344
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
Steven Bosscher changed:
What|Removed |Added
Known to work||4.6.3
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #25 from Steven Bosscher 2013-03-06
12:10:31 UTC ---
(NB 4.6.3 known to work w.r.t. comment #5, not w.r.t. original bug report)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #28 from Steven Bosscher 2013-03-06
12:18:01 UTC ---
(In reply to comment #22)
> Posted for discussion here:
> http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html
OT: Another trivial speed-up for bitmaps used as regsets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #25 from Steven Bosscher 2013-03-07
00:08:26 UTC ---
(In reply to comment #24)
> (In reply to comment #22)
> > 4.8.0 -O2 (terminated after 9 minutes waiting, LIM being the offender, I
> > suspect domwalk ...) >2.5GB
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #26 from Steven Bosscher 2013-03-07
00:26:56 UTC ---
(In reply to comment #23)
> FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 )
> can be compiled with 'clang', albeit slowly:
...
> Memory consu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #27 from Steven Bosscher 2013-03-07
08:09:59 UTC ---
Compilation finished after ~3 hours and consuming at least 3GB (from top - I
forgot to use memmax2...).
Winners in the "geez, I'm slow for this test case" list:
PRE
|unassigned at gcc dot |steven at gcc dot gnu.org
|gnu.org |
--- Comment #31 from Steven Bosscher 2013-03-07
09:58:03 UTC ---
(In reply to comment #30)
Hmm, RTL PRE isn't really mine either, but I probably know it as well as
anyone else, so I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #35 from Steven Bosscher 2013-03-07
17:30:58 UTC ---
(In reply to comment #34)
> Memory consumption appears to be the same as with -O2.
Can you measure the peak memory with time?
/usr/bin/time -f 'real=%e user=%U system=%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #36 from Steven Bosscher 2013-03-07
17:33:28 UTC ---
(In reply to comment #29)
> Yeah, one of my minor TLC patches. Most of the excessive memory
> usage for regular testcases can be fixed by doing LIM on
> all siblings of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #38 from Steven Bosscher 2013-03-07
22:15:39 UTC ---
Created attachment 29612
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29612
Punt on loops with more memory references than LIM can handle
For the LIM problem, I'm t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #39 from Steven Bosscher 2013-03-07
23:18:48 UTC ---
Memory usage is still pathetic. Some stats:
mem stats from /proc/self/statm on *entry* of pass:
pass (#) sizeresident
*warn_unused_re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339
--- Comment #8 from Steven Bosscher 2013-03-08
18:49:09 UTC ---
(In reply to comment #6)
> So - what regressed this compared to 4.7? It wasn't regmove.c changes.
Probably LRA, it better respects IRA's choices (which is good). The fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #43 from Steven Bosscher 2013-03-09
14:57:52 UTC ---
The problem with combine is only "collateral damage" from what dse1 is
doing to this function. It's loading stored values into registers and
replacing re-loads with those re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #44 from Steven Bosscher 2013-03-09
17:25:46 UTC ---
Created attachment 29628
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29628
Re-use store register if possible
This patch resolves the issue mentioned in comment #43
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #45 from Steven Bosscher 2013-03-11
09:40:18 UTC ---
Patches posted:
* Restrict GIMPLE loop invariant code motion of loop-invariant loads and
stores to loops with fewer memory references than a certain maximum that
is contro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54970
Steven Bosscher changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56593
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54896
--- Comment #8 from Steven Bosscher 2013-03-12
18:23:29 UTC ---
With r196576 on x86_64 (gcc17):
at -O1:
alias stmt walking : 30.99 (36%) usr
reload CSE regs : 18.94 (22%) usr
CSE : 14.94 (17%) usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54970
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
--- Comment #1 from Steven Bosscher 2013-03-12
19:54:05 UTC ---
Confirmed, compiling with -mcpu=power7 -msvx -O3 -fno-unroll-loops
Comes from here:
Breakpoint 8, doloop_modify (loop=0x3fffb5dc0ee0, desc=0x111d6d00,
doloop_seq=0x3fffb5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
Steven Bosscher changed:
What|Removed |Added
CC|steven at gcc dot gnu.org |
--- Comment #3 from Steven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
Steven Bosscher changed:
What|Removed |Added
Summary|[4.6/4.7/4.8 Regression]|Generate one fewer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--- Comment #21 from Steven Bosscher 2013-03-13
20:09:42 UTC ---
(In reply to comment #20)
> Ok, the goal would be to have all !targetm.legitimate_constant_p ()
> constants assigned to a pseudo (and in GIMPLE to an SSA name).
I'm not s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
--- Comment #23 from Steven Bosscher 2013-03-13
20:13:32 UTC ---
Honza, ping?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #12 from Steven Bosscher 2013-03-13
20:37:23 UTC ---
Curious to hear whether "-fschedule-insns -fsched-pressure" helps.
At least from the %esp and %ebp counts, it looks hopeful:
$ ./cc1 -quiet -m32 -O2 t.c -DNAIL_REGS -o t.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Steven Bosscher changed:
What|Removed |Added
Keywords||patch
Last reconfirmed|2011-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55996
--- Comment #5 from Steven Bosscher 2013-03-13
22:34:37 UTC ---
Fix for DSE causing combine compile time and memory explosion:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00379.html (rationale)
http://gcc.gnu.org/ml/gcc-patches/2013-03/ms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468
--- Comment #8 from Steven Bosscher 2013-03-16
23:46:08 UTC ---
(In reply to comment #7)
> Fixed on trunk and 4.7 branch so far, the fix will also be done for 4.8.1
It's unusual for a bug to be fixed for a previous release and for trunk,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54627
Steven Bosscher changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56651
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
Steven Bosscher changed:
What|Removed |Added
Keywords||ra
Status|UNCONFIR
1 - 100 of 1051 matches
Mail list logo
