https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103422
Bug ID: 103422
Summary: -march=bogus12323123423452345 -march=armv8-a is
accepted
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103420
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103421
--- Comment #1 from Andrew Pinski ---
Only the last march is passed down to cc1 which does the verification of the
option :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103421
Bug ID: 103421
Summary: -march=bogus12323123423452345 -march=skylake-avx512 is
accepted as a command line option
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 102611, which changed state.
Bug 102611 Summary: [C++23] P2128R6 - Multidimensional subscript operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8e86218f05c1a866b43ae5af3e303f91fb6d7ff0
commit r12-5511-g8e86218f05c1a866b43ae5af3e303f91fb6d7ff0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #9 from Richard Biener ---
In particular MOVE_RATIO only looks applicable if the target (or RTL
expansion?) would split the bigger GIMPLE move into pieces honoring MOVE_MAX.
Though technically even MOVE_MAX only guarantees:
"The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b38c9cf6d570f6c4c1109e00c8b81d82d0f24df3
commit r12-5510-gb38c9cf6d570f6c4c1109e00c8b81d82d0f24df3
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103420
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103420
Bug ID: 103420
Summary: libatomic fails to compile on aarch64 linux with
TFLAGS="-mcpu=octeontx2"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103416
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103412
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #7 from rguenther at suse dot de ---
On Thu, 25 Nov 2021, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
>
> --- Comment #6 from Hongtao.liu ---
> (In reply to Hongtao.liu from comment #5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44011
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
--- Comment #3 from Hongtao.liu ---
(In reply to H.J. Lu from comment #2)
> Created attachment 51871 [details]
> A patch
>
> Hongtao, please take a look.
Yes, i'll use type of second parameter which should be integer type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
--- Comment #2 from H.J. Lu ---
Created attachment 51871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51871=edit
A patch
Hongtao, please take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
Bug ID: 103419
Summary: FAIL: gcc.target/i386/pr102566-10b.c with -mx32
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #8 from HaoChen Gui ---
I refined the patch and put all things in a helper - change_pseudo_and_mask. As
you mentioned, it's still a band-aid. The perfect solution might be a better
version of nonzero_bits. Thanks.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
--- Comment #5 from Tamar Christina ---
This is a somewhat latent bug in CSE where merge_equiv_classes assumes that all
entries into the equivalence table are unique but CSE makes no attempt to
enforce this constraint.
So inserting the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #5 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 51870 [details]
> gcc12-pr103417.patch
>
> Untested fix. Handling GE in that simplification is clearly bogus, we
> should just fold it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401
--- Comment #4 from Marek Polacek ---
I think the patch might be just:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7508,6 +7508,8 @@ cp_parser_postfix_expression (cp_parser *parser, bool
address_p, bool cast_p,
looking at a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
--- Comment #4 from kargl at gcc dot gnu.org ---
This fixes/catches the type mismatch in the issue raised in comment #1.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 705d2326a29..0a864da015b 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #6 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Richard Biener from comment #3)
> > (In reply to H.J. Lu from comment #2)
> > > (In reply to Richard Biener from comment #1)
> > > > It isn't the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #1 from Andrew Pinski ---
The two main changes during that time period was jump threading and modref.
modref seems might be more likely with wrf being fortran code and even using
nested functions and such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
--- Comment #3 from kargl at gcc dot gnu.org ---
The patch in comment #2 does not address the issue in comment #1.
The patch only address an invalid BOZ in a structure constructor.
The issue in comment #1 is technical unrelated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-11-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103386
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Summary|stage1 with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401
--- Comment #3 from Marek Polacek ---
This is trickier than it seemed.
void f(decltype(auto(0))) { }
is actually valid in C++23 (probably) since auto(x) is supported. So I think
it's essentially like
void f(int) { }
The r11-1913 change is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
CC||johelegp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103415
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103244
--- Comment #4 from test test ---
(test, ignore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #3 from Segher Boessenkool ---
(In reply to luoxhu from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > Confirmed.
> >
> > So the relevant insn
> >
> > (parallel [(set (reg:CC 123)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 2bf21434a42..971c2fa1dd6 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
Tulio Magno Quites Machado Filho changed:
What|Removed |Added
CC||tuliom at ascii dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #11 from joseph at codesourcery dot com ---
The sign of a NaN result is never specified in C except for fabs,
copysign, negation, unary + (and assignment to the same format in the case
where that's copy rather than convertFormat).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103382
--- Comment #4 from Jonathan Wakely ---
Yes, it's just a lot of work to implement correctly, and non-zero overhead to
change the cancellation state.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
G. Steinmetz changed:
What|Removed |Added
Summary|[PDT] [10/11/12 Regression] |[PDT] ICE in
|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:56b3036c531929e0dae1103b9f5d20c82643415f
commit r11-9308-g56b3036c531929e0dae1103b9f5d20c82643415f
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102718
Thomas Schwinge changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #3 from Jakub Jelinek ---
generic_simplify_GE_EXPR is called with
BIT_FIELD_REF & 4294967040U
and
0U
arguments, and transforms that into
BIT_FIELD_REF <= 255. That is wrong,
(BIT_FIELD_REF & 4294967040U) >= 0U
is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
Andrew Pinski changed:
What|Removed |Added
Version|unknown |12.0
Summary|wrong code at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #1 from Andrew Pinski ---
It worked at r12-5485-ge1d4359264585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
Bug ID: 103418
Summary: random_number() does not accept pointer, intent(in)
array argument
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211124 (experimental) [master r12-5505-g5deacf6058d] (GCC)
[558] %
[558] % gcctk -O0 small.c; ./a.out
[559] %
[559] % gcctk -O1 small.c
[560] % ./a.out
Aborted
[561] %
[561] % cat small.c
struct {
int a : 8;
int b : 24;
} c = {0, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #4 from John S ---
I can Confirm from my side that it does appear to be the memmove inline
expansion and not the auto vectorizer. It also occurs with
builtin_memset/builtin_memcpy as well.
For some context, this is an issue would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87711
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:3e6b9910e8e23d690fa1026b2879d37745ddd740
commit r11-9307-g3e6b9910e8e23d690fa1026b2879d37745ddd740
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
--- Comment #17 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:3e6b9910e8e23d690fa1026b2879d37745ddd740
commit r11-9307-g3e6b9910e8e23d690fa1026b2879d37745ddd740
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
Eric Gallager changed:
What|Removed |Added
Status|SUSPENDED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 98750, which changed state.
Bug 98750 Summary: does not detect dead code [-Wunreachable-code-break]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
Eric Gallager changed:
What|Removed |Added
CC||tiagomacarios at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103416
--- Comment #1 from Chung-Lin Tang ---
Can you see if adding this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583279.html
fixes this problem? If so, then it should be another occurrence of PR90030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
--- Comment #12 from Jakub Jelinek ---
Note, sys/sdt.h is using the "nor" constraints for 11 years already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
--- Comment #11 from Jakub Jelinek ---
Inline asm that only works with memory but in constraints says it accepts both
immediate constant and memory is IMNSHO just broken, it is just fine if the
compiler makes a different choice.
If "nor" with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103416
Bug ID: 103416
Summary: [12 Regression][OpenMP] Bogus firstprivate(n) map(to:n
[len: 4][implicit])
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
--- Comment #10 from Richard Earnshaw ---
It's been this way now for over 20 years. A single instruction cannot take a
constant and a memory for the same operand, so this has been used in the
backend to trigger the minipool generation: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-11-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103412
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103415
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103415
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103415
Bug ID: 103415
Summary: [12 Regression] ICE in cpp_interpret_string_1, at
libcpp/charset.c:1739
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
Bug ID: 103414
Summary: [10/11/12 Regression] ICE in gfc_free_actual_arglist,
at fortran/expr.c:547
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
Bug ID: 103413
Summary: [10/11/12 Regression] ICE: Invalid expression in
gfc_element_size
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103412
Bug ID: 103412
Summary: [10/11/12 Regression] ICE: Invalid expression in
gfc_element_size
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
Bug ID: 103411
Summary: ICE in gfc_conv_array_initializer, at
fortran/trans-array.c:6377
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103410
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2021-11-24
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 71843, which changed state.
Bug 71843 Summary: [concepts] Diagnostics issued for constraint satisfaction
failure fail to elucidate unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71843
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103386
--- Comment #2 from mittorn at sibmail dot com ---
Removing -floop-nest-optimize -floop-interchange -fgraphite-identity fixes
build, but removing only -fgraphite-identity not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
Jakub Jelinek changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103410
Bug ID: 103410
Summary: ICE: in grokfndecl, at cp/decl.c:9903
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Bug ID: 103409
Summary: 18% WRF compile-time regression with -O2 -flto between
g:1ae8edf5f73ca5c3 and g:1ae8edf5f73ca5c3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
--- Comment #8 from Richard Earnshaw ---
OK, so the real problem in the test case is the constraint ("nor") is
meaningless on Arm (because there is no instruction in the architecture that
can accept both a constant and a memref) and this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103408
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103408
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103408
Bug ID: 103408
Summary: ICE when requires auto(x) in C++23
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405
--- Comment #8 from Jan Hubicka ---
Created attachment 51868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51868=edit
Patch in testing
Good to know that there are no more known modref & Ada problems ;) I recently
extended modref to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403
--- Comment #4 from Enrico Maria De Angelis ---
So there is a relation between this problem and PR 78209. At least a
cause-effect relation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103379
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103382
--- Comment #3 from Ivan Sorokin ---
> Huh, I thought it was noexcept. Then yes, we should remove it.
Thank you very much! I'm looking forward for a fix.
> There are still lots of other places where the stadnard does require
> 'noexcept' and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103379
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
1 - 100 of 200 matches
Mail list logo
