https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118533
Peter Bergner changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #11 from Peter Bergner ---
(In reply to Sam James from comment #8)
> I'm still seeing this, but I think it's an actual bug, not a testism.
I will restate that Surya's IRA commit is a correct fix, so the
missed-optimization bug lies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #8 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #7)
> So, what happened with this PR? I see the patch has been reviewed and small
> nits requested to be changed, but then I don't see it being committed nor
> repost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
--- Comment #12 from Peter Bergner ---
(In reply to Janis Johnson from comment #4)
> The tests also fail on powerpc64-linux, although the first one gets the same
> error with and without optimization.
>
> elm3c105% cat 43374-1.c
> int func(_Deci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #5 from Peter Bergner ---
(In reply to Kewen Lin from comment #4)
> (In reply to Peter Bergner from comment #3)
>> There look to be more effective target tests we need a similar fix for.
>
> Yes, there is PR113535 opened tracking fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #3 from Peter Bergner ---
(In reply to Michael Meissner from comment #0)
> gcc.dg/vect/pr112325.c
This is compiling some explict vector code, so I wouldn't expect this to run on
power4, but it does. I would have thought the dg-requ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #2 from Peter Bergner ---
(In reply to Michael Meissner from comment #0)
> gcc.target/powerpc/pr92488.c
This is a DFP runtime test and it seems for pre-power6 (ie, pre DFP hardware
insns), we get a precision difference with power6 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #1 from Peter Bergner ---
(In reply to Michael Meissner from comment #0)
> I build a GCC trunk on the gcc110 cfarm system. I got the following
> failures when I built GCC without using --with-cpu=. These failures
> are gone if I us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #2 from Peter Bergner ---
With the scalar version, we have in the fwprop dump:
propagating insn 5 into insn 6, replacing:
(set (reg:DI 120 [ var ])
(mem/c:DI (reg/f:DI 119) [1 var+0 S8 A64]))
successfully matched this instructio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109073
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-11-20
Target|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
If we compile some simple test cases returning the value from a global vector
array, we fail to fold the low 16-bits of the offset into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117444
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Component|target |testsuite
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117444
--- Comment #1 from Peter Bergner ---
Well that patch disables jump tables for -O0 and the test case assumes they'll
be generated. The test case is not compiled with any optimization levels, so
we could either explicitly add -O1 or -fjump-table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #11 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Peter Bergner from comment #4)
> > These die because the struct we're using to check the alignment of uses long
> > double as the "big" aligne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #13 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #12)
> (In reply to Peter Bergner from comment #10)
> > void
> > stack_limit_increase (unsigned long pref ATTRIBUTE_UNUSED)
> > {
> > #if defined(HAVE_SETRLIMIT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #10 from Peter Bergner ---
(In reply to Andreas Schwab from comment #8)
> See PR c++/49756. It uses 64MB, not unlimited.
[bergner@ltcden2-lp1 ICE]$ ulimit -s 8192
[bergner@ltcden2-lp1 ICE]$ /opt/gcc-nightly/trunk/bin/gcc -S test.c
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #7 from Peter Bergner ---
(In reply to Richard Biener from comment #5)
> I agree it's difficult to solve. GCC tries to up the stack limit to
> unlimited, why isn't this working for you? Maybe we should remember the
> failure to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
Peter Bergner changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #1 from Peter Bergner ---
Created attachment 59434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59434&action=edit
gzip'd test case that segvs
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Compiling the attached simple but large test case, we seem to run out of stack
space which causes an ICE. The test case declares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
--- Comment #9 from Peter Bergner ---
(In reply to munroesj52 from comment #8)
> looks good, thanks.
So everything that was asked for is now implemented so we can close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #9 from Peter Bergner ---
(In reply to Jonathan Wakely from comment #8)
> Could it be the call to __builtin_cpu_supports("darn") which happens in the
> std::random_device x("default") initialization in test01?!
>
> Could that system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
In the following test case, the "n & 4" test is redundant and should be
eliminated, since the "n &= 7;" statement limits n's p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #10 from Peter Bergner ---
Fixed on trunk with a slightly different (but functionally identical) patch
than posted above. I'll let it sit there for a few days to ensure we didn't
expose any other issues with the patch before backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #6 from Peter Bergner ---
(In reply to Peter Bergner from comment #5)
> I'm testing a fix.
>
> Our P8 swap optimization has some special handling for TImode usage. The
> __atomic_compare_exchange call introduces a PTImode use and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Peter Berg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #4 from Peter Bergner ---
Here's a C testcase that shows the same problem:
bergner@ltcden2-lp1:BUG$ cat bug.c
#include
#include
typedef union {
struct {
uint64_t a;
uint64_t b;
} t;
__uint128_t raw_data;
} Value;
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #2 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
||2024-08-16
Ever confirmed|0 |1
CC||bergner at gcc dot gnu.org,
||guihaoc at gcc dot gnu.org,
||linkw at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-08-14
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
--- Comment #2 from Peter Bergner ---
(In reply to Kewen Lin from comment #0)
> I think not having TARGET_P10_VECTOR isn't intentional, as we still allow
> -mno-vsx with -mcpu=power10. We have TARGET_P8_VECTOR and TARGET_P9_VECTOR
> for P8 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #18 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #17)
> Does it also work if you spell the option name correctly? All unknown
> configure
> options are always accepted silently.
Sorry, it was a typo here, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #16 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #14)
> So, can you explain how could libquadmath build at all in such
> configurations?
> __float128 type is supported and not TFmode?
> Is that because it is KFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> Yup, that sounds eminently plausible :-) Thanks.
For the given that error message, yes, it seems plausible. But I don't know
how an error like that can b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061
--- Comment #5 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #4)
> Actually not that, but
> s/int g;/short int g;/
Yes, this does not abort with either -m32 or -m64 for me. The other suggestion
still aborted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061
--- Comment #2 from Peter Bergner ---
It's the same code on powerpc64le-linux and it passes, so the uninitialized
stack space we load must be zero?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061
Peter Bergner changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
--- Comment #13 from Peter Bergner ---
(In reply to Peter Bergner from comment #11)
> Fixed on trunk. I'll push the backports after a little burn-in time on
> trunk.
All of Bill's CI testers were green wrt this test case, so I've started
backpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103548
Peter Bergner changed:
What|Removed |Added
Known to fail|12.0|
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
||2024-07-18
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Peter Bergner ---
Confirmed and mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #11 from Peter Bergner ---
Fixed on trunk. I'll push the backports after a little burn-in time on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Peter Bergner changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #2 from Peter Bergner ---
(In reply to Kewen Lin from comment #0)
> As Peter found in the PR115688, there isn't a warning for:
>
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
> return 0;
> }
>
> It's expecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #6 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> (In reply to Peter Bergner from comment #4)
> > That said, how does your patch handle the following test case?
> >
> > long __attribute__ ((target ("no-alt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #4 from Peter Bergner ---
(In reply to Kewen Lin from comment #2)
> // 32 bit has altivec_abi unset, so that's why it doesn't ICE at -m64.
Ah yes, that does explain the difference between 32-bit and 64-bit!
...and that means it ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-06-27
CC|
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
After r15-703-gb390b011569635, we're seeing test case pr111380-2.c ICE on
32-bit BE compiles. It hits the new gcc_assert from the commit above. The
failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #11 from Peter Bergner ---
(In reply to Kewen Lin from comment #10)
> (In reply to Peter Bergner from comment #9)
> > (In reply to Kewen Lin from comment #8)
> > > Should be fixed on trunk, it's not a regression, but we probably want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #7 from Peter Bergner ---
Patch for item 3. submitted.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655164.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #27 from Peter Bergner ---
FYI, as part of the work for PR114759, I have come to the conclusion that
disabling shrink-wrapping in the presence of -mrop-protect is a big hammer and
we shouldn't really need to do that. I plan on "fixi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
--- Comment #6 from Peter Bergner ---
Fixed on trunk. I will let it burn-in on trunk for a couple of days before
pushing the backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||il/gcc-patches/2024-June/65
||4397.html
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
--- Comment #4 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> So, what value do we output? And why?
The invalid offset is zero, so: hashst r0,0(r1)
As the assembler mentions, the range of valid offsets is [-512,-8] and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262
--- Comment #2 from Peter Bergner ---
(In reply to Jeffrey A. Law from comment #1)
> It looks like the test wants to see xxsel, but after that change we get
> xxlor and what looks like a slight difference in register allocation. I
> can't real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We emit a hashst instruction with an invalid offset when compiling with
-mabi=no-altivec.
bergner@ltcd97-lp3:~/ROP$ cat bug.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #7 from Peter Bergner ---
The test fails when setToIdentityBAD's index var is unsigned int. It passes
when using unsigned long long, unsigned long, unsigned short and unsigned char.
When using unsigned long long/unsigned long, we d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #6 from Peter Bergner ---
Created attachment 58361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58361&action=edit
setToIdentityBAD-char.s
Code generated for setToIdentityBAD.c when using unsigned char for the index
variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #5 from Peter Bergner ---
FYI, fails for me with gcc 12 and later and works with gcc 11. It also fails
with -O3 -mcpu=power10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #9 from Peter Bergner ---
(In reply to Kewen Lin from comment #8)
> Should be fixed on trunk, it's not a regression, but we probably want
> backporting this?
For code correctness bugs, yes, we want them backported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #25 from Peter Bergner ---
(In reply to Michael Meissner from comment #23)
> 3) Only build the IEEE 128-bit libgcc bits if the user configured the
> compiler with --with-cpu=power7, --with-cpu=power8, --with-cpu=power9,
> --with-cpu=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #14 from Peter Bergner ---
(In reply to Niels Möller from comment #13)
> I'm not that familiar with gcc development procedures. Do I understand you
> correctly, that a fix for this bug will not be included in gcc-14 (according
> to h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
Peter Bergner changed:
What|Removed |Added
Depends on||101129
--- Comment #4 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
--- Comment #2 from Peter Bergner ---
(In reply to Peter Bergner from comment #1)
> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake? Thanks.
I'll note I used -O1 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #5 from Peter Bergner ---
(In reply to Peter Bergner from comment #4)
> If instead we want to just silently ignore (or with a warning), we'd just
> need to modify the rs6000.cc hunk to disable rs6000_rop_protect instead of
> calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #4 from Peter Bergner ---
Created attachment 57977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57977&action=edit
Patch that emits an error for invalid ROP option combinations.
Here's a patch that treats invalid ROP option c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
>> 1. We always define the __ROP_PROTECT__ predefined macro [snip]
>
> No. Whenever the -mrop-protect option is in effect, we should do that
> predefine.
Wh
,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Target||powerpc64le-linux
Last
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
There are multiple issues with the -mrop-protect option which are all
inter-related.
1. We always define the __ROP_PROTECT__ predefined macro when using
-mrop-protect, even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 69031, which changed state.
Bug 69031 Summary: ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC
-fselective-scheduling and __builtin_setjmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Peter Bergner changed:
What|Removed |Added
Known to fail||12.0, 13.0, 14.0
--- Comment #2 from Pet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #21 from Peter Bergner ---
Fixed on trunk. I'll let it burn-in there for a bit before backporting to the
release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
1 - 100 of 1230 matches
Mail list logo
