https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114264
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
Summary|[13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110327
--- Comment #3 from Jeffrey A. Law ---
Two block copies isn't fatal when the second one is the one with the actual
jump thread. But costing does get more complex.
Basically we copy 8 so that we can isolate its two incoming paths which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110503
--- Comment #7 from Jeffrey A. Law ---
As you note, this feels like a failure to recognize that only one value can
actually satisfy the condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538
--- Comment #3 from Jeffrey A. Law ---
Thread references removed edge: Cancelling jump thread: (9, 10) incoming
edge; (10, 8) joiner (8, 6) normal;
Thread references removed edge: Cancelling jump thread: (2, 3) incoming edge;
(3, 9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
--- Comment #8 from Jeffrey A. Law ---
Note that Richi was supportive of the patch and just asked for a few minor
changes. Pinski, if you wanted to take care of Richi's comments we could get
this one off the P2 list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110931
--- Comment #5 from Jeffrey A. Law ---
One could also look at this as a failure to propagate.
l.0_1 = l;
t_4 = (short int) l.0_1;
if (t_4 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
We ought to be able to propagate l.0_1 into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
Jeffrey A. Law changed:
What|Removed |Added
CC||rzinsly at ventanamicro dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111798
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Jeffrey A.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293
--- Comment #10 from Andrew Pinski ---
Here is some more optimizations where the inner CMP is not EQ/NE:
signed:
x == (x <= CST) -> CST == 0 ? false : CST < 0 ? x == 0 : x == 1
x == (x < CST) -> CST == 1 ? false : CST <= 0 ? x == 0 : x == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
--- Comment #6 from Jeffrey A. Law ---
I'd hazard a guess we need to first eliminate the ad = assignment. That
should in turn allow us to realize ad is unchanging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111801
--- Comment #2 from Jeffrey A. Law ---
Interestingly enough this is picked up at -O3. Looks like PRE does a better
job and the result is easier to discover the range for first operand of the
controlling conditional.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
Jeffrey A. Law changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112545
--- Comment #2 from Jeffrey A. Law ---
This looks like a missed case for singletons.
_1 = d.9_28 <= 0;
_2 = (signed short) _1;
_3 = (signed short) d.9_28;
c.a = 0;
if (_2 == _3)
goto ; [0.00%]
else
goto ; [100.00%]
Back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113433
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #5 from John David Anglin ---
This is what we have from reload with Sam's reduced test case:
(insn 9 103 123 2 (set (reg/f:SI 1 %r1)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3e8ee03edd018eed43444755f601cdb9d5931654
commit r14-9406-g3e8ee03edd018eed43444755f601cdb9d5931654
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f4a52c184d608325c14338b57f464f7d0bbc7526
commit r14-9405-gf4a52c184d608325c14338b57f464f7d0bbc7526
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
--- Comment #9 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:54e505d0446f86b7ad383acbb8e5501f20872b64
commit r14-9403-g54e505d0446f86b7ad383acbb8e5501f20872b64
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114222
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law changed:
What|Removed |Added
Assignee|law at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #4 from Jeffrey A. Law ---
BTW, the P4 designation is primarily because I suspected this would likely be a
PA specific issue. If it turns out to be a generic problem, it would probably
immediately bump to P1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
--- Comment #5 from Andrew Pinski ---
Or it is a dup of bug 55658. Either way dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364
Andrew Pinski changed:
What|Removed |Added
CC||dan at stahlke dot org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
John David Anglin changed:
What|Removed |Added
Last reconfirmed||2024-03-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
--- Comment #3 from Dan Stahlke ---
Variants that generate more reasonable results:
struct foo {
int x:32;
} __attribute__((packed));
struct foo {
int x:16;
} __attribute__((packed));
struct foo {
int x:31;
};
struct foo {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Dan Stahlke changed:
What|Removed |Added
Target|x86_64-linux-gnu|
Keywords|missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Bug ID: 114289
Summary: Non-optimal assembly for accessing bit-fields in
packed structs
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
Bug 106201 depends on bug 94894, which changed state.
Bug 94894 Summary: avoidable instantiation of conversion function template
during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105766
Bug 105766 depends on bug 94894, which changed state.
Bug 94894 Summary: avoidable instantiation of conversion function template
during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107188
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #6 from Andrew Pinski ---
(In reply to Antoni from comment #4)
> A load in LLVM returns undef, so it is not UB. The problem is in
> rustc_codegen_gcc itself.
Right, GCC gimple semantics are different from LLVM semantics. GCC gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #5 from Antoni ---
(In reply to Andrew Pinski from comment #3)
> >Rust will sometimes copy uninitialized memory and I'd like to avoid
> >disabling this specific warning.
>
>
> Note in C, there are specific rules about copying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #4 from Antoni ---
(In reply to Andrew Pinski from comment #3)
> >Rust will sometimes copy uninitialized memory and I'd like to avoid
> >disabling this specific warning.
>
>
> Note in C, there are specific rules about copying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #8 from Kees Cook ---
Clang bug: https://github.com/llvm/llvm-project/issues/84565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #7 from Kees Cook ---
There is still no way to use C99 flexible arrays in unions (or alone in
structs) without syntactic obfuscation. The extension that already allows
0-sized arrays in unions should be extended to cover C99 arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
Kees Cook changed:
What|Removed |Added
CC||carlos at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #21 from Steve Kargl ---
On Fri, Mar 08, 2024 at 08:01:02PM +, kyle.shores44 at gmail dot com wrote:
>
> (In reply to Steve Kargl from comment #19)
> >
> > It seems your code is hitting a NULL pointer dereference when
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #20 from Kyle Shores ---
(In reply to Steve Kargl from comment #19)
> On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
> >
> > --- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
--- Comment #2 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:cebbaa2a84586a7345837f74a53b7a0263bf29ee
commit r14-9401-gcebbaa2a84586a7345837f74a53b7a0263bf29ee
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #19 from Steve Kargl ---
On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
>
> --- Comment #17 from Kyle Shores ---
> I was able to get tuv-x to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #3 from Andrew Pinski ---
>Rust will sometimes copy uninitialized memory and I'd like to avoid disabling
>this specific warning.
Note in C, there are specific rules about copying unitialized memory. Most is
it is undefined. It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287
--- Comment #2 from Andrew Pinski ---
Anyways the fortran code in SPEC is borken. See the long thread in PR 69368
about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Andrew Pinski changed:
What|Removed |Added
CC||manolis.tsamis at vrull dot eu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113777
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2024-03-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #11 from Sam James ---
Calling it a 11..14 regression as we know 14 is bad and 7.5 is OK, but I can't
test 11/12 on an avx512 machine right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #10 from Christoph Erhardt ---
I have just verified that the reproducer program I attached above
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027#c4) still crashes as
expected on Fedora 39 with GCC 13.2.1. It's not super-tiny,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
--- Comment #9 from Marek Polacek ---
Oh and I meant to say it's the DECL_DECLARED_INLINE_P check that makes the
difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196
Patrick O'Neill changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
--- Comment #8 from Marek Polacek ---
(In reply to Patrick Palka from comment #7)
> I noticed we emit the function if we turn it into a non-member:
>
> #include
>
> constexpr int VAL = 1;
>
> template
> void bar(typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196
Patrick O'Neill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #18 from Kyle Shores ---
(In reply to Steve Kargl from comment #16)
> On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com
> wrote:
> > I have not made a smaller example, but we have since removed json-fortran
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #17 from Kyle Shores ---
I was able to get tuv-x to compile by putting use statements in problematic
files at the top of the module. In one case, I had to match the use ordering to
the order that the objects were used in the module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #16 from Steve Kargl ---
On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com wrote:
> I have not made a smaller example, but we have since removed json-fortran as a
> dependency for tuv-x.
>
> So it should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
Andreas Fertig changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 114242, which changed state.
Bug 114242 Summary: Coroutine with lambda-coroutine and operator new does not
compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
--- Comment #6 from Jakub Jelinek ---
struct S { char c[1024]; };
int foo (int);
__attribute__((returns_twice, noipa)) struct S
bar (int x)
{
(void) x;
struct S s = {};
s.c[42] = 42;
return s;
}
void
baz (struct S *p)
{
foo (1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
--- Comment #5 from Jakub Jelinek ---
Adjusted testcase which shows more cases, like multiple edges into the
returns_twice bb in addition to the edge from .ABNORMAL_DISPATCHER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:ac829a89fb56cfd914d5e29ed4695e499b0dbc95
commit r14-9399-gac829a89fb56cfd914d5e29ed4695e499b0dbc95
Author: Richard Earnshaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
--- Comment #4 from Jakub Jelinek ---
Thinking about it, I'd say this should be instrumented differently between asan
and ubsan. ubsan, which ought to just check whether the pointer is non-NULL
and properly aligned, should instrument it in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #15 from Kyle Shores ---
To reiterate how this issue can sometimes be resolved, if I take use statements
out of subroutines and place them at the top of a module, files can then be
compiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #14 from Kyle Shores ---
I have not made a smaller example, but we have since removed json-fortran as a
dependency for tuv-x.
So it should be easier to view the failure in tuv-x. I have not made the time
to try to reduce the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113660
--- Comment #1 from Alexandre Oliva ---
There's nothing specific about -fharden-control-flow-redundancy here, FWIW.
ISTM that it just adds enough EH-related stuff to the function that an EH note
gets attached to the impossible asm, a stmt then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 103256, which changed state.
Bug 103256 Summary: [modules] Internal compiler error after using iostream and
filesystem as modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103256
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103256
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102536
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 102536, which changed state.
Bug 102536 Summary: [modules] ICE Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102536
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105489
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 105489, which changed state.
Bug 105489 Summary: [modules] Internal Compiler Error for 6 line source code
(using C++20 modules) doing nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105489
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 101433, which changed state.
Bug 101433 Summary: [modules] Bad File Data from simple function returning
std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433
Patrick Palka changed:
What|Removed |Added
Target Milestone|11.5|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |11.5
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 101224, which changed state.
Bug 101224 Summary: Problem with interaction of modules and std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101224
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
Patrick Palka changed:
What|Removed |Added
CC||p.cross13 at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101224
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 113930, which changed state.
Bug 113930 Summary: [modules] checking ICE in register_duplicate when using
partitioned modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229
--- Comment #7 from Patrick Palka ---
*** Bug 113930 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110905
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
1 - 100 of 222 matches
Mail list logo
