--- Comment #4 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-07 21:32 ---
The patch has almost no effect except for -Os. For SPEC binaries the
effect of the patch is not exactly shocking on AMD64 at least: No effect
at all on compile time, no effect on performance, and almost no effect
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-07 21:33 ---
This is somehow a bug in sched-ebb, but I can't figure out where...
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-07 21:55 ---
I guess something like this should work if Andrew was right in comment #6.
Obviously this doesn't fix the the test case from comment #1 because we
don't go through this code if a user codes an "at
--- Comment #13 from steven at gcc dot gnu dot org 2005-10-07 21:57 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-07 21:58 ---
I have no time to work on this. Note that there is no test case anymore
either, so it's hard to tell whether a fix is doing the right thing.
--
steven at gcc dot gnu dot org changed:
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-08 07:20 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-12 19:37 ---
What about this
Index: c-decl.c
===
RCS file: /cvs/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.687
diff -u -3 -p -r1.687 c-decl.c
--- c-decl.c
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-12 20:58 ---
The patch mentioned in #2 is not sufficient anymore. copy propagation and VRP
also propagate copies of this kind. And may_propagate_copy is not used in most
places, and even when it _is_ used, it doesn't
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-12 20:58 ---
Mark, this is probably not fixable for GCC 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16306
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-13 20:38 ---
What should be done with this meta-bug? The remaining pending patches
are all large patches from Joern that add new functionality, but they
do not fix regressions. Move forward to 4.2?
--
steven at gcc dot gnu
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-15 17:25 ---
This patch from Jim Wilson makes the ICE go away for me:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00886.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-15 17:25 ---
reopening...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #18 from steven at gcc dot gnu dot org 2005-10-15 17:26 ---
...to fix a mouse click on the wrong radio button :-)
*** This bug has been marked as a duplicate of 24232 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from steven at gcc dot gnu dot org 2005-10-15 17:26 ---
*** Bug 23948 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2005-10-15 17:27 ---
argh
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-15 17:29 ---
...to fix a mouse click on the wrong radio button :-/
*** This bug has been marked as a duplicate of 24232 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from steven at gcc dot gnu dot org 2005-10-15 17:29 ---
*** Bug 23857 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from steven at gcc dot gnu dot org 2005-10-16 23:20 ---
On AMD64, I now get the following timings:
-O1 -O2
3.3 (profilebootstrapped) 46.64 46.90
4.1 (checking=release) 72.82 156.43
In 4.1, the Big Spenders are "domi
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-17 09:27 ---
Comments #4 and #5 suggest that there is still some slowdown compared to
gcc 3.4 and earlier, but we know what the problems are and we have open
bug reports for those problems.
Since this bug is now inactive for
--- Comment #18 from steven at gcc dot gnu dot org 2005-10-17 09:27 ---
*** Bug 20945 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-17 09:29 ---
What is the deal here? Is there a bug, or not? If so, can someone
confirm the bug, and otherwise close it as invalid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22042
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23302
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-17 09:35 ---
Re. comment #5 -- it's always a possibility ;-)
Just show that it's worth it. I doubt it is, really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--- Comment #20 from steven at gcc dot gnu dot org 2005-10-17 09:41 ---
Yes, further work is planned on this. Someone just needs to figure out
what is still eating so much time. If you can compile with -ftime-report
and report back the top 10 compile time consumers, that'd be he
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-17 15:09 ---
If you add a line to the test case:
printf ("%d\n", offsetof (CABINETSTATE, fMenuEnumFilter));
you get 2 for GCC 4.1, and 4 for GCC 3.3.
So this is definitely an ABI change.
--
steven at gcc dot g
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-17 18:54 ---
The patch identified in comment #2 has nothing to do with this problem. Pinski
is right in comment #1, loop-invariant.c does not verify that the insns it
moves/inserts are valid. Using emit_move_insn is just one
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-18 21:30 ---
It does make sense to allow this if the (other) industry standard C++ compiler
allows this in !pedantic mode. For backward source compatibility if nothing
else.
--
steven at gcc dot gnu dot org changed
--- Comment #17 from steven at gcc dot gnu dot org 2005-10-18 22:24 ---
We want to cgraph_varpool_mark_needed_node the rhs of the #pragma weak, but by
the time we get to maybe_apply_pending_pragma_weaks, we only have the
identifier, and AFAICT no way to find the appropriate symbol that
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-19 13:13 ---
That patch is yet another example of why we constantly keep having compile time
problems. Just add more, and more, and more, and more. And act surprised when
someone notices that gcc 4.1 is four times as slow as
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-19 15:47 ---
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.224
diff -u -3 -p -r2.224 tree-cfg.c
--- tree-cfg.c 16 Oct 2005 00
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-19 15:51 ---
And did fjahanian take a look at this already to see if he
really is to blame for causing this bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-20 21:03 ---
Created an attachment (id=10035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10035&action=view)
Hack that makes the test case work. Needs testing.
--
steven at gcc dot gnu dot org
--
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 #4 from steven at gcc dot gnu dot org 2005-10-20 21:11 ---
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01260.html
Ignore the wrong bug number. This is just the same patch as the one
in comment #2.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-20 21:40 ---
Created an attachment (id=10036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10036&action=view)
Alternate fix
As suggested by Andrew Pinski...
Put loci on the stack save and restore operations.
Thi
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-20 22:45 ---
The second fix boostraps the compiler proper and it builds libstdc++ and
libgfortran without problems. But it fails on cp-demangle.c for some reason.
That's probably another case where we don't put
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-21 11:07 ---
Honza, Richi... well? Is anyone going to do anything with this bug? :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-21 11:13 ---
I do not consider this to be a regression, really.
Store motion was always broken. There are reasons for why it is disabled
by default ;-)
pinskia, what do you think: Keep this marked as a regression, or not
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-21 11:15 ---
Andreas, are you going to post your patch from comment #4?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-21 11:21 ---
How do you know this is hppa-linux only now? There's a bit if information
missing about how you got to that conclusion.
Is there some simple way to test this bug on HPPA? (Maybe add a HPPA
maintainer to t
--
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 #3 from steven at gcc dot gnu dot org 2005-10-23 20:45 ---
Fixed by commiting Asher's patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-23 20:46 ---
Note that we have the g77 behavior: BYTE maps to INTEGER(kind=1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22175
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-23 21:16 ---
This doesn't ICE for me.
So this should be "accepts-invalid" now, or we could call it a GNU extension
and only disallow it in stricter standard enforcement modes. Or we could just
close it.
Erik, yo
--- Comment #54 from steven at gcc dot gnu dot org 2005-10-23 21:19 ---
Following comments #52 and #53, I'm removing the wrong-code keyword.
I'm all for closing this long-open bug. But maybe we should keep it open until
some automatic testing process is in place.
--
ste
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16465
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-23 21:37 ---
Alright, accepts-invalid it is for GCC 4.1.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2005-10-24 21:19 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-24 21:20 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-24 21:21 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from steven at gcc dot gnu dot org 2005-10-25 15:30 ---
Backtrace:
Breakpoint 1, fancy_abort (file=0xb1cc18
"../../mainline/gcc/tree-ssa-loop-ivopts.c",
line=2948, function=0xb1d0bb "aff_combination_to_tree") at diagnostic.c:590
590 intern
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-25 16:24 ---
Jakub, ping!
Are you going to post your patch from comment #4??
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-25 22:00 ---
Re. comment #4, this may not be a bug in your eyes, but then it is still at
least an enhancement request.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24531
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-26 17:46 ---
Re. comment #5, yes other library ABIs change too, but libgfortran is special
in that what shipped with GCC 4.0 was highly experimental and never intended to
be a stable interface. The decision at the time was that
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-26 18:54 ---
Perhaps this cures it.
Index: interface.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/interface.c,v
retrieving revision 1.21
diff -u -3 -p -r1.21
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-27 11:26 ---
Huh, how can this ICE be a duplicate of an accepts-invalid bug??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24554
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-27 16:26 ---
Could the dear reported at least try to provide a small test case?
I think this should not be marked as a regression. It's just sad that this
kind of non-bug keeps the regression count high, when in reality GC
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-27 17:08 ---
And CSiBE tells you the story that GCC 4.1 produces smaller code overall.
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-os&basephp=s-i686-linux
So do the SPEC benchmark boxes btw.
--
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-27 17:31 ---
For the record, we're talking about:
1.file "t.c"
2.text
3.p2align 4,,15
4
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-27 17:34 ---
And FWIW there is also a problem with this insn, the length is wrong:
#(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61])
#(mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])) 44 {*mov
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #13 from steven at gcc dot gnu dot org 2005-10-28 15:58 ---
Smaller test case:
// Compile with -O2 -maltivec
//
// Works with GCC 3.3.5 and GCC 4.0.2
// ICEs with GCC 4.1 from today's CVS
#include
#define RE
--- Comment #14 from steven at gcc dot gnu dot org 2005-10-28 16:22 ---
More background:
Starting program: /abuild/stevenb/build/gcc/cc1 -O2 -maltivec t.c -da
foo
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
foo
Breakpoint 8, find_reloads
--- Comment #15 from steven at gcc dot gnu dot org 2005-10-28 16:59 ---
The trouble appears to come from this:
case V16QImode:
case V8HImode:
case V4SFmode:
case V4SImode:
case V4HImode:
case V2SFmode:
case V2SImode:
case V1DImode:
if (CONSTANT_P
--- Comment #16 from steven at gcc dot gnu dot org 2005-10-28 17:01 ---
On IRC it was suggested that we just need to get a version of
easy_vector_constant which does the right thing in any mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-29 15:11 ---
I'm testing the patch from comment #8 on a few targets.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-29 15:15 ---
How can this possibly be a GCC 4.0/4.1 regression?!
Before GCC 4.0 we didn't even have a Fortran with support for derived types.
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-29 16:28 ---
This does not fail for me... Neither the original test case nor the reduced
one. The compiler I used was "GNU C++ version 4.1.0 20051029 (experimental)
(x86_64-unknown-linux-gnu)"
--
http://gcc.gnu.or
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-29 16:41 ---
This does ICE for i686 or for AMD64 -m32. For 64 bits it passes for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-29 21:52 ---
You'll have to investigate the drop a bit more. That patch you identified was
supposed to fix the performance problems of a previous fix for some bug. It
should not have any adverse effects. You'll have t
RMED
Keywords: ice-on-invalid-code
Severity: minor
Priority: P2
Component: c++
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=24582
--- Comment #1 from steven at gcc dot gnu dot org 2005-10-29 22:10 ---
Created an attachment (id=10080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10080&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
--- Comment #26 from steven at gcc dot gnu dot org 2005-10-29 22:36 ---
Waiting for someone to look into this...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from steven at gcc dot gnu dot org 2005-10-29 22:38 ---
amacleod, are you going to post your patch and/or commit it??
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-29 22:43 ---
Is the only problem here one single extra SET produced by expand, or do we have
a bug here somewhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23335
--
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 #6 from steven at gcc dot gnu dot org 2005-10-31 07:21 ---
This was not a show stopper for GCC 3.4 and GCC 4.0. Why is it a show stopper
now for GCC 4.1?
And we can't unconditionally change it back now. We already have GCC 3.4 and
4.0 based compilers in produ
--- Comment #26 from steven at gcc dot gnu dot org 2005-10-31 17:12 ---
Moving back to new, because I don't know if the GCSE CPROP issue with implicit
sets is also already fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #18 from steven at gcc dot gnu dot org 2005-10-31 17:14 ---
See comment #16 for a patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-31 17:31 ---
Right, I didn't know this wasn't opened until July of this year, sorry.
I should have looked.
I still am not sure whether this does break a documented ABI. Relevant
texts in C99 are 6.2.6.1 sub 4, and 6.7
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-31 23:14 ---
I have asked Janis to reghunt this one. The bug also affects ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-01 16:44 ---
The mail to gcc-patches for the patch identified in comment #11 is
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00209.html.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-01 23:08 ---
-fno-tree-loop-im fixes it too, fwiw.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-01 23:09 ---
Most likely aliasing related.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2005-11-01 23:09 ---
Mark, this is a new wrong-code bug.
Could you look at it and set a priority please.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2005-11-02 22:55 ---
What are the flags for the sizes in comment #7 and comment #8?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
--- Comment #4 from steven at gcc dot gnu dot org 2005-11-03 08:50 ---
We have the following two options:
- Make loop.c preserve the profile. We all know that's not doable.
- Backport the loop-invariant.c changes from the killloop-branch
and enable -fmove-loop-invariants when
--- Comment #9 from steven at gcc dot gnu dot org 2005-11-03 21:00 ---
Jakub, ping!
What's up with this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-03 21:00 ---
Jakub, ping!
What's up with this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-08 10:47 ---
Trunk today produces this (with -dAP hacked to print slim RTL):
.file "t.c"
.text
.align 2
.global longfunc
.type longfunc, %function
longfunc:
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-08 10:51 ---
Add an ARM guy to the CC:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-08 11:15 ---
test:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl func
add sp, sp, #12
--- Comment #6 from steven at gcc dot gnu dot org 2010-02-08 11:18 ---
Does the ARM backend already support conditional compares?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-08 11:22 ---
Patch of comment #3 from Ramana was never committed to the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-08 11:29 ---
Trunk today (r156595) produces this:
repl1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
mov r4, r0
mov r1, #0
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-08 12:14 ---
Richard, can we split thumb2_compare_scc? If so, when/how would you do this?
(I'm thinking of a post-RA splitter, but perhaps it could be done earlier.)
--
steven at gcc dot gnu dot org changed:
1301 - 1400 of 3051 matches
Mail list logo
