https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #35 from Huaqi ---
OK, thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
George Bott changed:
What|Removed |Added
CC||george at bott dot gg
--- Comment #34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> This was built on solaris 2.10 so maybe the solution is just to update
> /opt/csw/bin/gcc. I'll ask the cfarm admins about that.
That wouldn't help,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
Bug ID: 109492
Summary: gcc/fortran/trans-expr.cc:3407:17: error: call of
overloaded ‘abs(long long int&)’ is ambiguous
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161
--- Comment #3 from Indu Bhagat ---
Excerpt from the generated DWARF debug info:
<1><32>: Abbrev Number: 3 (DW_TAG_subprogram)
<33> DW_AT_external: 1
<33> DW_AT_name: (indirect string, offset: 0x12c4): set_cpu_arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #5 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #4)
>
> Can you git bisect this to find the offending commit?
Yes, I was going to start that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #4 from Peter Bergner ---
(In reply to pthaugen from comment #0)
> Created attachment 54845 [details]
> Reduced testcase
>
> Hitting the following segfault on the attached testcase (sorry for size, but
> it is about 1% of original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #9 from Segher Boessenkool ---
That patch looks fine :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #3 from Andrew Pinski ---
Created attachment 54846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54846=edit
Removed altivec intrinsics
This changes the altivec intrinsics except for __builtin_vec_mergeh which I
just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #2 from Andrew Pinski ---
I should note while trying to test this on x86_64 (removing the altivec
specific intrinsics) the compile time was large even for -O0. It was ok with
-fsyntax-only though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #1 from pthaugen at gcc dot gnu.org ---
Note this only happens on a BE system, compiles fine on LE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|Segfault in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Bug ID: 109491
Summary: Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #8 from Wilhelm M ---
Yes. Looks like the patch does its job.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #32 from Marek Polacek ---
(In reply to maic from comment #31)
> Would be nice if this was re-opened, or should a new bug be filed?
This is the same problem as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165#c9
Unfortunately,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #31 from maic ---
Would be nice if this was re-opened, or should a new bug be filed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109483
--- Comment #5 from Andrew Pinski ---
(In reply to Uroš Bizjak from comment #4)
> Even the above is not optimal. I'd expect:
>
> ...
> .L8:
> #APP
> # 6 "t.c" 1
> int3
> # 0 "" 2
> #NO_APP
> je .L2
> xorl%eax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> The behavior also depends on the order of USE statements in the main:
>
> USE H5T
> USE ISO_C_BINDING
>
> differs from
>
> USE ISO_C_BINDING
> USE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490
Bug ID: 109490
Summary: ICE when using custom OpenMP reduction in Lambda in
Template Function
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
--- Comment #6 from Oliver Rosten ---
If you're sure.
The only thing which gives me pause for thought is that the problem I see with
source_location only occurs when I also see
ld: warning: direct access to global weak symbol means the weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
--- Comment #5 from Andrew Pinski ---
(In reply to Oliver Rosten from comment #4)
> I think I've come across a case where this is symptomatic of a serious
> problem -see https://github.com/ojrosten/SourceLoc
That seems totally unrelated to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
Oliver Rosten changed:
What|Removed |Added
CC||oliver.rosten at googlemail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69200
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #13)
> > This PR may be a duplicate of others that describe gfortran's confusion
> > when using (intrinsic) modules along a module chain like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #5 from Andrew Pinski ---
Note I think clang's "optimization" might get the case where a subdirectory is
not "executable" but is readable wrong.
So this is definitely something which would need testing too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2015-07-22 00:00:00 |2023-4-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Andrew Pinski changed:
What|Removed |Added
CC||wumingchuan1992 at foxmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109481
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
Andrew Pinski changed:
What|Removed |Added
Summary|Feature request: More |improve include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #2 from Andrew Pinski ---
Also does it work with Windows style pathes?
I am suspecting clang does not do the right thing there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489
Bug ID: 109489
Summary: [ubsan] Support -fsanitize-trap=
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #1 from Andrew Pinski ---
Is this even valid with NFS?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488
Bug ID: 109488
Summary: typo in lang.opt: libraries maybe
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #13 from Bernhard Reutner-Fischer ---
(In reply to anlauf from comment #12)
> Consider the original testcase. Module CModule has no public symbols.
> Technically, the "use CModule" in module DModule should not have any effect.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #6 from Wilhelm M ---
The following "solution"
constexpr uint16_t mul(const uint8_t a, const uint16_t b) {
const auto aa = std::bit_cast>(b);
return aa[1] * a;
}
or
constexpr uint16_t mul(const uint8_t a, const uint16_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108291
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108291
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ae8f903632c930694640a925b042c87e3bdb7200
commit r13-7157-gae8f903632c930694640a925b042c87e3bdb7200
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #5 from Segher Boessenkool ---
Correct, this certainly can not be done by combine, it see two independent
pseudos here. For hard registers it *can* do many tricks, but not for
pseudos like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580
--- Comment #5 from Jonathan Wakely ---
I've implemented the suggested changes to istreamubf_iterator and also proposed
them as a resolution for LWG 2366 https://wg21.link/lwg2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420
--- Comment #2 from Patrick Palka ---
FWIW a candidate fix has been posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615250.html and will
hopefully get reviewed/pushed later this week
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #34 from Costas Argyris ---
Hi Huaqi,
Patch has been pushed to master, you should now be able to get the latest gcc
sources and build without having to apply it manually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
--- Comment #3 from Jakub Jelinek ---
The Simple Location Description before each DW_OP_{,bit_}piece may be empty,
that is the
DWARF 5 2.6.1.1.1 Empty Location Descriptions.
Sorry for my wording issue earlier, where I wrote Single I meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
--- Comment #2 from LU Hongyi ---
Oh, sorry I didn't read the standard carefully.
But still, the code generated by GCC still looks a bit strange.
There is a DW_OP_const2u between two composite location descriptor.
The final DWARF generated by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
--- Comment #7 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:31eb8f18bbe64613fd8d77c4520c00beeb13598f
commit r13-7156-g31eb8f18bbe64613fd8d77c4520c00beeb13598f
Author: Ju-Zhe Zhong
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109458
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:51856718a82ce60f067910d9037ca255645b37eb
commit r13-7155-g51856718a82ce60f067910d9037ca255645b37eb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109458
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4073ce2c4e5584c1be58fbe76dd66285de2529bb
commit r13-7154-g4073ce2c4e5584c1be58fbe76dd66285de2529bb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #31 from Costas Argyris ---
(In reply to Tobias Burnus from comment #30)
> I see commit r13-7153-g3beeebd6934654f3453209730b98c7a1fd0305b6
> "mingw: Support building with older gcc versions"
>
> And I see in the associated email to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109483
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #2)
> Note that clang seems to propagate the constant equivalence which we
> instead un-propagate. With -fdisable-tree-uncprop1 you'll get the
> expected code:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
Bug ID: 109487
Summary: GCC generates redundant DWARF information after
DW_OP_stack_value.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109472
--- Comment #2 from Marc Poulhiès ---
Regression starts from:
a8d17a88a52d2f773423adb55399d23ed5ea03c8 is the first bad commit
commit a8d17a88a52d2f773423adb55399d23ed5ea03c8
Author: Piotr Trojanek
Date: Tue Jun 21 10:17:57 2022 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:14f0ea22413fe3e64306c57fbfd2ae7b5769c1a1
commit r13-7151-g14f0ea22413fe3e64306c57fbfd2ae7b5769c1a1
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109451
--- Comment #2 from Paul Thomas ---
Created attachment 54842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54842=edit
Fix for this PR
To my surprise, the identified bug was very easily fixed and the associate
block that seemed to be OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104515
Richard Biener changed:
What|Removed |Added
CC||pshevchuk at pshevchuk dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109486
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109486
--- Comment #2 from Richard Biener ---
Btw, -fno-lifetime-dse is a workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109486
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982
--- Comment #9 from Scot Breitenfeld ---
This is Great! Thank-you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109449
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
--- Comment #13 from Sam James ---
(In reply to Sam James from comment #12)
> Per 24af552876eff707f75d30d3f0f0e7a5d62dd857
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462#c7) and the test being
> XFAILed, I think this is now unfixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 101912, which changed state.
Bug 101912 Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Sam James changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108
Bug 97108 depends on bug 101912, which changed state.
Bug 101912 Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #8 from m.cencora at gmail dot com ---
Ah, I see that gcc doesn't support nested designated initializer in C++ mode
(compared to C mode, or clang in both C and C++ modes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109448
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> Not when s_addr is a macro for S_un.S_addr or something like that.
The real definition on Solaris is more like:
struct in_addr {
union {
struct {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Costas Argyris changed:
What|Removed |Added
Attachment #54838|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478
--- Comment #2 from Jeffrey A. Law ---
The pa.cc bits look reasonable. It's been forever since I looked at this code,
but clearly using a HOST_WIDE_INT is the right thing to be doing. While it may
not fix this bug completely, consider it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
--- Comment #7 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:24af552876eff707f75d30d3f0f0e7a5d62dd857
commit r13-7150-g24af552876eff707f75d30d3f0f0e7a5d62dd857
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108139
--- Comment #7 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:24af552876eff707f75d30d3f0f0e7a5d62dd857
commit r13-7150-g24af552876eff707f75d30d3f0f0e7a5d62dd857
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109486
Bug ID: 109486
Summary: Optimization regression with pseudodestructors
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #6 from Jonathan Wakely ---
I did try it.
It's also not valid in older standards, so would give pedantic warnings with
-Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #5 from Jonathan Wakely ---
Not when s_addr is a macro for S_un.S_addr or something like that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #6 from 。 <570070308 at qq dot com> ---
A better testcase:
```c
void kkk(void **const pp)
{
void *temp;
__asm__ volatile (
"movq $0xff, %0\n\t"
"movq $0xff, %1"
:"=r"(temp), "=m"(*pp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109480
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:9f10b4957ca6058d1a801c5e4bfe11bf159da809
commit r13-7149-g9f10b4957ca6058d1a801c5e4bfe11bf159da809
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Richard Biener changed:
What|Removed |Added
Component|target |rtl-optimization
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #28 from Costas Argyris ---
I am not aware of any cases of building windows-hosted gcc with msvc or clang.
If the combination -r -nostdlib fixes this case without breaking all the others
that don't need -nostdlib (which sounds like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Jonathan Wakely changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
1 - 100 of 186 matches
Mail list logo
