https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96184
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102255
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0458154caafc5438cecf1db8cf96076e384244ab
commit r12-3436-g0458154caafc5438cecf1db8cf96076e384244ab
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #7 from Hongtao.liu ---
And here is invalid subreg from general_operand
#ifdef INSN_SCHEDULING
/* On machines that have insn scheduling, we want all memory
reference to be explicit, so outlaw paradoxical SUBREGs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #3 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #2)
> See https://wg21.link/cwg1228 this might be invalid code and GCC is correct
> in rejecting it.
Maybe. But why does GCC accept the following?
#include
#include
int mai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264
--- Comment #2 from Nicholai Tukanov ---
(In reply to Andrew Pinski from comment #1)
> There seems to be some extra moves the register allocator cannot remove and
> that is causing some extra spilling.
>
> Your loop has 32 live variables and tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268
--- Comment #1 from Davin McCall ---
(fails with -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #6 from Hongtao.liu ---
Another testcase cut from pr102154
#define MODFL __builtin_modfl
void foo() {
long iptrll;
MODFL(0.5l, (long double *)&iptrll);
}
$ ./xgcc -B. pr48641.c -frounding-math -Og -fno-tree-fre
pr48641.c: In fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268
Bug ID: 102268
Summary: Wrong code with aliasing union pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #5 from Hongtao.liu ---
and also ICE for (subreg:DF(reg:SF)), but ok for (subreg:v2df(reg:SF)0)
void
foo (void)
{
float x;
*((double *) &x) = 0;
}
typedef double v2df __attribute__((vector_size(16)));
void
foo1 (v2df a)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267
--- Comment #3 from Andrew Pinski ---
Yes the problem is GCC is broken for all comparison of declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #4 from Hongtao.liu ---
Yes, also ICE for x86_64-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
Summary|Can't compare pointers to |Can't compare pointers to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
Andrew Pinski changed:
What|Removed |Added
Severity|normal |major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #11 from Andrew Pinski ---
*** Bug 102267 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267
Bug ID: 102267
Summary: Can't compare pointers to instantiated variables
during constant evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.1.0, 4.8.1, 9.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #7 from Andrew Waterman ---
On Tue, Sep 7, 2021 at 10:55 PM wilson at gcc dot gnu.org via Gcc-bugs
wrote:
>
> The hardware may trap if
> you access a 32-bit value which is not properly NaN-boxed.
I don't think the following affects
On Tue, Sep 7, 2021 at 10:55 PM wilson at gcc dot gnu.org via Gcc-bugs
wrote:
>
> The hardware may trap if
> you access a 32-bit value which is not properly NaN-boxed.
I don't think the following affects the resolution of the ticket, but
just for the record, trapping is _not_ an option the ISA pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
Segher Boessenkool changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38557
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #11 from Patrick McGehearty
---
Thanks!
On 9/9/2021 5:54 PM, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
>
> --- Comment #10 from Andrew Pinski ---
> (In reply to Patrick McGehearty from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #10 from Andrew Pinski ---
(In reply to Patrick McGehearty from comment #9)
r12-228-g54f0224d55a1b56dde092460ddf76913670e6efc
Just making it easier for links here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
Patrick McGehearty changed:
What|Removed |Added
CC||patrick.mcgehearty at oracle
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #20 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #18)
> So I wonder if it makes sense to allow lowpart subregs of any mode when
> the inner mode is integer.
We really really really should make a separate b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39549
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102265
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
Andrew Pinski changed:
What|Removed |Added
Component|c |inline-asm
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
Bug ID: 102266
Summary: RFE: x86: print operand with optional (%rip) suffix
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264
--- Comment #1 from Andrew Pinski ---
There seems to be some extra moves the register allocator cannot remove and
that is causing some extra spilling.
Your loop has 32 live variables and that is just at the limit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-09-09
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988
--- Comment #1 from anlauf at gcc dot gnu.org ---
*** Bug 53699 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53699
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=102262
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102265
Bug ID: 102265
Summary: s390: Inefficient code for __builtin_ctzll
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45464
--- Comment #3 from Andrew Pinski ---
Actually I think only the warning for the three add case is wrong and here is
why:
adding two (unsigned) 8bit integers together will only give you a max a 9bit
integer.
so comparing b and (a+a) is fine
Addin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264
Bug ID: 102264
Summary: Macro Intrinsics fail to use all the registers on the
machine
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #2 from Andrew Pinski ---
See https://wg21.link/cwg1228 this might be invalid code and GCC is correct in
rejecting it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247
--- Comment #4 from TC ---
See also PR 60027 and its duplicates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90284
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #1 from Jonathan Wakely ---
Well it works fine on other systems, which is probably why nobody noticed it.
I have no way to debug this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814
Andrew Pinski changed:
What|Removed |Added
CC||tower120 at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-09-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102258
--- Comment #2 from Johel Ernesto Guerrero Peña ---
That still doesn't work because you can't compare (the addresses of) different
`std::type_info` objects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
--- Comment #11 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5fe0865ab788bdc387b284a3ad57e5a95a767b18
commit r12-3432-g5fe0865ab788bdc387b284a3ad57e5a95a767b18
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102250
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #19 from seurer at gcc dot gnu.org ---
This also prevents gcc from being built if it includes go on powerpc LE:
libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102263
Bug ID: 102263
Summary: Requesting enhanced warning on returning
pointer/reference to local
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-09
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102258
--- Comment #1 from Johel Ernesto Guerrero Peña ---
Workaround for my use-case: https://godbolt.org/z/5Woe8dvan.
```C++
#include
#include
#include
#include
#include
struct B { virtual ~B() = default; };
struct D : B { int x{1}; constexpr ~D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262
Bug ID: 102262
Summary: No reason given for constexpr function that uses
non-constexpr destructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102261
Bug ID: 102261
Summary: [12 Regression] ICE: Segmentation fault (in
build_this_conversion)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102260
Andrew Stubbs changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
t;binutils). LLVM 9 is known to work, LLVM 10 to 13
don't work, with LLVM 13 bailing outin the libgcc gfx900 configure:
configure:3566: /packages/gcc/snap/gcc-snapshot-20210909/build-gcn/./gcc/xgcc
-B/packages/gcc/snap/gcc-snapshot-20210909/build-gc
n/./gcc/ -nostdinc
-B/packages/gcc/snap/gcc-sn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229
--- Comment #8 from Jason Merrill ---
(In reply to Marek Polacek from comment #6)
> Thanks. With the latter interpretation in mind, it seems my earlier fix
> should be mitigated so that we allow
>
> constexpr decltype(auto)
> but not
> conste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
--- Comment #5 from Giuseppe D'Angelo ---
Here's a further testcase that doesn't even use unique_ptr:
#include
#include
using ptr = int *;
using rawptr = int *;
#ifndef RESTRICT
#define RESTRICT
#endif
void swap(ptr & RESTRICT a, ptr & RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
Bug ID: 102259
Summary: ifstream::read(…, count) fails when count >= 2^31 on
darwin
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102258
Bug ID: 102258
Summary: dynamic_cast to derived type fails during constant
evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229
--- Comment #7 from Net Can ---
here is my use case:
https://github.com/netcan/config-loader/blob/master/include/config-loader/serialize/TypeSerializer.h
the key is
```c++
#define TYPE_SERIALIZER(_type, _typeName) \
struct T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Bug ID: 102257
Summary: call of overloaded 'tuple' is ambiguous
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102255
Richard Biener changed:
What|Removed |Added
Target|i[34567]86-*-cygwin*, |i[34567]86-*-cygwin*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102256
Bug ID: 102256
Summary: target uses STABS by default
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981
--- Comment #7 from Thibaut M. ---
There are other regressions (in term of code size) but not sure if this is the
same.
For example, this code:
```C
#include
void big_switch(int a) {
switch (a) {
default:
printf("default a(%d)\n", a);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102255
Bug ID: 102255
Summary: target uses STABS by default
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> And maybe also should throw away (with a warning) or turn into
> __builtin_unreachable () during GIMPLE passes. Because it is a clear UB.
Yes, a candidate for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #2 from TC --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
Bug ID: 102254
Summary: [12 Regression] ICE: in extract_insn, at recog.c:2769
(error: unrecognizable insn)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
--- Comment #3 from ktkachov at gcc dot gnu.org ---
The RTL for the offending insn:
(insn 9 8 10 (set (reg:VNx16BI 68 p0)
(mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
(const_int 8 [0x8]))
(reg/f:D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-09-09
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
--- Comment #1 from Richard Biener ---
replacing the loop bound 1024 with 'b' moves the two offenders off the radar
leaving, with N == 1
ipa function summary : 12.91 ( 11%) 0.00 ( 0%) 12.92 ( 11%)
9800k ( 0%)
loop ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
--- Comment #6 from Andrew Pinski ---
Here is a testcase which will hit the warning on all targets and not just ILP32
specific ones:
int
foo (_Bool x)
{
int v = 0;
return (v & ~1u) | (1u & (x << 0));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
Bug ID: 102253
Summary: scalability issues with large loop depth
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
--- Comment #1 from Gilles Gouaillardet
---
Created attachment 51430
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51430&action=edit
a test that works
FWIW, the attached test_svfloat.cpp passes.
It is very similar to test_svbool.cpp but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
Bug ID: 102252
Summary: svbool_t with SVE can generate invalid assembly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33262
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #13 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #12)
> One issue is that _addcarry_u64 / x86intrin.h are not documented, so the
> conditions of its use in portable code are not clear. I suppose that it is
> desig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #12 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #11)
> x86 has _addcarry_u64 which gets it mostly (see PR 97387).
>
> The clang builtins __builtin_*_overflow are there but not the __builtin_add*
> builtins.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102251
--- Comment #1 from Andrew Pinski ---
Understanding [expr.cond]/3 part of the standard is hard ...
Also EDG and GCC produce the same results here. Very similar to PR 87605.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100851
--- Comment #4 from michaldrozd at protonmail dot ch ---
PR 91737 seems similar enough to be related
I've narrowed it down to the -Wl,-init functionality, if you comment out this
lines it exits cleanly.
https://github.com/eclipse/paho.mqtt.c/blob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
--- Comment #5 from Richard Biener ---
I think the warning should work on unfolded (un-narrowed) trees or
shorten_binary_op should from a INTEGER_TYPEd operation not create a
BOOLEAN_TYPEd one (but maybe simply build a unsigned int:1 for it)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102243
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102251
Bug ID: 102251
Summary: Valid code is rejected in ternary operator with unique
conversion
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #18 from rguenther at suse dot de ---
On Wed, 8 Sep 2021, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
>
> --- Comment #17 from Segher Boessenkool ---
> (In reply to Hongtao.liu from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #29 from Toon Moene ---
On 9/8/21 10:05 PM, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
>
> anlauf at gcc dot gnu.org changed:
>
> What|Removed |Added
>
99 matches
Mail list logo
