http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975
Steven Bosscher changed:
What|Removed |Added
Keywords||wrong-code
CC|
||2012-07-19
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Steven Bosscher 2012-07-19
11:04:32 UTC ---
(In reply to comment #1)
> Something peculiar here is that the default and anot
||steven at gcc dot gnu.org
Resolution||INVALID
--- Comment #1 from Steven Bosscher 2012-07-20
13:43:53 UTC ---
Creating a PCH is not always possible. You can have only one PCH per project.
See http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2012-07-20
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Steven Bosscher 2012-07-20
18:02:42 UTC ---
I like the idea, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54008
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
||2012-07-21
CC||steven at gcc dot gnu.org
Component|middle-end |gcov-profile
Ever Confirmed|0 |1
||2012-07-21
CC||steven at gcc dot gnu.org
Component|middle-end |gcov-profile
Ever Confirmed|0 |1
||2012-07-21
CC||steven at gcc dot gnu.org
Component|middle-end |gcov-profile
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27453
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
,
||rguenth at gcc dot gnu.org,
||steven at gcc dot gnu.org
--- Comment #15 from Steven Bosscher 2012-07-21
23:25:38 UTC ---
Matz's patch http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html was never
committ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32543
--- Comment #1 from Steven Bosscher 2012-07-21
23:37:05 UTC ---
Author: steven
Date: Sat Jul 21 23:37:02 2012
New Revision: 189748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189748
Log:
PR gcov-profile/32543
* profile.c (branc
||steven at gcc dot gnu.org
Resolution||FIXED
--- Comment #2 from Steven Bosscher 2012-07-21
23:38:16 UTC ---
trivial but it still took almost 5 years to do something about it.
Sorry it took so long.
||2012-07-21
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Steven Bosscher 2012-07-21
23:57:18 UTC ---
A tool to merge multiple gcda files shoulnd't be very difficult to write. I
||steven at gcc dot gnu.org
Resolution||FIXED
--- Comment #3 from Steven Bosscher 2012-07-22
00:02:22 UTC ---
I don't see in what way this is not fixed...
||2012-07-22
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Steven Bosscher 2012-07-22
00:04:44 UTC ---
The best way around this, is to use -fprofile-generate and -fprofile-use.
But it
||2012-07-22
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Steven Bosscher 2012-07-22
00:07:38 UTC ---
Tru64 is not supported anymore. Rainer, since this is a regression, I haven
||2012-07-22
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #4 from Steven Bosscher 2012-07-22
00:11:31 UTC ---
I think the transformation should just be disabled completely if the checksums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
||steven at gcc dot gnu.org
--- Comment #3 from Steven Bosscher 2012-07-22
00:18:33 UTC ---
The proper place to post patches is gcc-patches. Much appreciated if you can
post your patch there, with an explanation of the problem and of why your patch
fixes it.
Is there a test case that
||2012-07-22
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
--- Comment #5 from Steven Bosscher 2012-07-22
10:23:37 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > A tool to merge multiple gcda files shoulnd't be very difficult to write. I
> > don't think this should be done by the compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
--- Comment #6 from Steven Bosscher 2012-07-22
10:46:30 UTC ---
(In reply to comment #2)
> We have one internally at Cavium which is designed to run afterwards and merge
> a few gcda file. It is designed for how we run multi-core programs and wr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881
Steven Bosscher changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #10 from Steven Bossche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54022
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881
--- Comment #11 from Steven Bosscher 2012-07-22
21:29:42 UTC ---
*** Bug 54022 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881
--- Comment #12 from Steven Bosscher 2012-07-23
09:26:46 UTC ---
Author: steven
Date: Mon Jul 23 09:26:41 2012
New Revision: 189779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189779
Log:
gcc/
PR tree-optimization/53881
* tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54068
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
||2012-07-23
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #5 from Steven Bosscher 2012-07-23
21:28:56 UTC ---
What are the callers of gt_pch_p_9line_maps?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #6 from Steven Bosscher 2012-07-23
22:46:19 UTC ---
FWIW this shows up in GCC's own libstdc++ PCHs also.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #9 from Steven Bosscher 2012-07-24
09:20:14 UTC ---
(In reply to comment #1)
> Boost version is 1.49.
> (When I use --save-temps and use the resulting .ii file instead, the
> regression
> is no longer reproducible)
That's of course
||steven at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Steven Bosscher 2012-07-24
15:31:50 UTC ---
I suspect this is a 64-bit pointer vs. 32-bit integer issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
--- Comment #6 from Steven Bosscher 2012-07-24
15:51:39 UTC ---
(In reply to comment #4)
> The questions are:
> 1, why pre does not do such optimization;
Because PRE (gcse.c) doesn't run at -Os.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
--- Comment #7 from Steven Bosscher 2012-07-24
18:16:17 UTC ---
Prototype patch attached to this email:
http://gcc.gnu.org/ml/gcc/2012-07/msg00189.html
It's not a finished patch, but it should be a good starting point for anyone
who really wants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
--- Comment #12 from Steven Bosscher 2012-07-25
08:24:49 UTC ---
(In reply to comment #9)
> I think a tool to merge would be a good partial solution.
We will go with the tool solution. I'll take care of the tool before GCC 4.8,
if that's OK with
||steven at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #1 from Steven Bosscher 2012-07-26
11:59:39 UTC ---
.
*** This bug has been marked as a duplicate of bug 54084 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084
Steven Bosscher changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084
--- Comment #7 from Steven Bosscher 2012-07-26
12:08:31 UTC ---
This is the variant of the patch that I will commit after testing:
Index: sel-sched-ir.c
===
--- sel-sched-ir.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084
--- Comment #8 from Steven Bosscher 2012-07-26
13:21:28 UTC ---
Author: steven
Date: Thu Jul 26 13:21:21 2012
New Revision: 189891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189891
Log:
PR regression/54084
* sel-sched-ir.c (cm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084
Steven Bosscher changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||2012-07-26
CC||steven at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35568
Steven Bosscher changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975
--- Comment #15 from Steven Bosscher 2012-07-26
23:45:51 UTC ---
(In reply to comment #14)
> So either we revert the patch at
> http://gcc.gnu.org/viewcvs?view=revision&revision=177658 or we add e.g.
> clobbers of address register to the check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975
--- Comment #16 from Steven Bosscher 2012-07-26
23:52:32 UTC ---
Patch post for r177658: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00353.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Steven Bosscher changed:
What|Removed |Added
Last reconfirmed|2011-12-24 00:00:00 |2012-07-29 0:00
CC|
||2012-07-29
CC|steven at gcc dot gnu.org |
AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
Steven Bosscher changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #21 from Steven Bos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #23 from Steven Bosscher 2012-07-30
11:08:01 UTC ---
(In reply to comment #22)
> Still a 98% compile time regression on todays trunk.
What revision number is this? If it includes r189951, could you please see if
you can get an update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
Steven Bosscher changed:
What|Removed |Added
Status|WAITING |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #26 from Steven Bosscher 2012-07-30
13:17:25 UTC ---
FWIW, the resulting PCH for GCC 4.8 is more than twice as large as the PCH for
GCC 4.7.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #27 from Steven Bosscher 2012-07-30
13:51:58 UTC ---
The problem is the quadratic behavior invoked by the loop in
gt_pch_nx_line_maps:
{
size_t l2 = (size_t)(((*x).info_macro).used);
if ((*x).info_macro.maps != N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823
Steven Bosscher changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #28 from Steven Bosscher 2012-07-30
14:22:37 UTC ---
With -ftrack-macro-expansion=2 (the default):
(gdb) call dump_line_table_statistics()
Number of expanded macros: 237994
Average number of tokens per macro expan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #29 from Steven Bosscher 2012-07-30
15:04:18 UTC ---
Created attachment 27897
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27897
Unswitched gtype-desc.c at r189965
Manually "unswitching" gt_pch_p_9line_maps gives me acceptable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #30 from Steven Bosscher 2012-07-30
16:15:35 UTC ---
Created attachment 27898
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27898
Hack to avoid quadratic loops
This makes use of the assumption that this_obj and its comparison c
gcc dot gnu.org
|gnu.org |
||steven at gcc dot gnu.org
Resolution||FIXED
--- Comment #2 from Steven Bosscher 2012-07-30
23:16:37 UTC ---
Fixed by tree-ssa's EH lowering and builtin_alloca handling.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51662
Steven Bosscher changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
||steven at gcc dot gnu.org
Resolution||FIXED
Target Milestone|--- |4.3.0
Known to fail||
--- Comment #51 from Steven Bosscher 2012-07-30
23:29:36 UTC ---
As per Danny's sugge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
Steven Bosscher changed:
What|Removed |Added
Status|REOPENED|NEW
Last reconfirmed|2006-09-03 21:39
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
--- Comment #6 from Steven Bosscher 2012-07-30
23:48:39 UTC ---
It's not clear to me how instantiate_pending_templates protects its
instantiations from GGC.
||2012-07-31
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Steven Bosscher 2012-07-31
08:00:38 UTC ---
Confirmed.
(You can try -fdump-rtl-all-slim for dumps that are easier to interpret.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #32 from Steven Bosscher 2012-07-31
09:21:03 UTC ---
Author: steven
Date: Tue Jul 31 09:20:56 2012
New Revision: 18
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=18
Log:
PR pch/53880
* gengtype.c (struct walk_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
Steven Bosscher changed:
What|Removed |Added
Known to fail|4.8.0 |
--- Comment #33 from Steven Bosscher
||2012-07-31
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #3 from Steven Bosscher 2012-07-31
20:33:56 UTC ---
Time is spent in add_scope_conflicts() in this loop:
FOR_EACH_BB (bb)
add_scope_conflicts_1 (bb, work, true);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #4 from Steven Bosscher 2012-07-31
22:16:58 UTC ---
Created attachment 27915
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27915
Speed up stack var conflict matric computation
The patch speeds up the conflict matrix computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
Attachment #27915|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133
--- Comment #3 from Steven Bosscher 2012-08-01
10:13:32 UTC ---
With "GCC: (GNU) 4.8.0 20120731 (experimental) [trunk revision 190015]" the
dumps look slightly different. I'm using the -fdump-rtl-all-slim dumps (with a
local patch to dump SEQUENC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133
--- Comment #4 from Steven Bosscher 2012-08-01
11:58:00 UTC ---
Created attachment 27918
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27918
Hack regmove to do limited propagation of hard regs
I have a patch to make the propagation happen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54150
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #7 from Steven Bosscher 2012-08-01
14:08:01 UTC ---
(In reply to comment #6)
> The inline heuristics stuff is probably also due to stack-vars handling,
> I will look into that.
Turns out this is due to the use of attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #8 from Steven Bosscher 2012-08-01
14:14:11 UTC ---
With the attribute((flatten)) removed, the full test case compiles in less than
a minute.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
--- Comment #11 from Steven Bosscher 2012-08-01
17:51:55 UTC ---
(In reply to comment #10)
> Fixed.
Is it still your plan to also do something with the patch to expose target
addressing modes earlier?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
Component|middle-end |tree-optimization
Summary|Ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54150
--- Comment #3 from Steven Bosscher 2012-08-03
08:22:12 UTC ---
Created attachment 27929
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27929
Adjust pp_flush as per suggestion of comment #1, and honor ~TDF_BLOCKS
Could the OP please give th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #14 from Steven Bosscher 2012-08-03
08:59:29 UTC ---
Created attachment 27930
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27930
Do not inline_merge_summary if called via flatten_function
As I noted in comment #12, the flatten
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54160
Steven Bosscher changed:
What|Removed |Added
Target||darwin*
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #4 from Steven Bosscher 2012-08-05
11:05:56 UTC ---
(In reply to comment #3)
> I think we should cast to unsigned first, then add.
No, see what happens to "case -12" if you use ((unsigned)s_1+16).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #5 from Steven Bosscher 2012-08-05
11:35:40 UTC ---
Just to illustrate:
$ cat t.c
#include
int
main (void)
{
int cases[] = { -16, -12, -9, -17 };
int i, v;
printf ("Show why cast must happen after add. T==1 iff (D.1732_8 != 0)\
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
Attachment #27917|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #9 from Steven Bosscher 2012-08-05
12:33:56 UTC ---
(In reply to comment #7)
> cc1 is writing about one line every 2 minutes to its assembler output file:
If you've really configured with --enable-stage1-checking=all, you've enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #10 from Steven Bosscher 2012-08-05
12:37:28 UTC ---
(In reply to comment #7)
> These memory requirements are solely due to the size of the .c file (1.8MB) .
This is indeed excessive, we'll have to look into this. If you have
preproc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #16 from Steven Bosscher 2012-08-05
13:54:30 UTC ---
> $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 \
> --enable-multilib --with-cpu-32=i686 --with-cpu-64=k8 \
> --enable-version-specific-runtime-libs \
> --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #17 from Steven Bosscher 2012-08-05
13:55:43 UTC ---
(In reply to comment #12)
> Average user doesn't build or use compiler. It is only done by developers
> which
> have modern PC which means 8 GB RAM.
Sorry, but this is just rubbis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #17 from Steven Bosscher 2012-08-05
18:48:55 UTC ---
(In reply to comment #14)
> if-conversion : 177.26 (but due to loop_optimizer_init)
Hmm, this is not loop_optimizer_init. All time is spent in the two memset calls
in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Steven Bosscher changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #25 from Steven Bos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #27 from Steven Bosscher 2012-08-05
21:05:41 UTC ---
(In reply to comment #26)
> And what has any of this to do with the simple question posed in the title
> of this bug report : why can't insn-emit.c be split ?
It could be split up.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #18 from Steven Bosscher 2012-08-05
21:13:26 UTC ---
Created attachment 27946
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27946
Speed up ifcvt.c:check_cond_move_block
This speeds up the pre-reload if-conversion passes by usin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #29 from Steven Bosscher 2012-08-06
09:10:49 UTC ---
(In reply to comment #27)
> Actually, I'm more interested in seeing if insn-emit.c can be reduced in size
> by avoiding duplicate functions (see e.g. gen_swapdi/gen_swapsi/gen_swapx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #30 from Steven Bosscher 2012-08-06
10:49:03 UTC ---
Created attachment 27950
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27950
Split insn-emit.c into four separate files
Untested, etc., and doesn't apply to GCC 4.7 because i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47489
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54150
Steven Bosscher changed:
What|Removed |Added
Attachment #27929|0 |1
is obsolete|
501 - 600 of 1051 matches
Mail list logo