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,
>
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
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
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=edit
Patch that emits an error for invalid ROP option combinations.
Here's a patch that treats invalid ROP option
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.
,
||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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #8 from Peter Bergner ---
(In reply to Andrew Pinski from comment #6)
> Note this implementation of sha2.c is shared all over the place it seems and
> has this known issue ...
(In reply to Andrew Pinski from comment #4)
> (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Component|target |ipa
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Known to work||11.0
CC|
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Building the dcfldd v1.9.1 package on powerpc64le-linux when configured to use
-O3 produces an incorrect sha256 sum for GCC trunk, 13 and 12. GCC 11 and
earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #13 from Peter Bergner ---
So I think the conclusion is we should close this as INVALID, correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #11 from Peter Bergner ---
(In reply to Richard Sandiford from comment #10)
> Yeah, I agree it's an error. The PR says “ICE”, but is there an internal
> error? The “cannot be used in ‘asm’ here” is a normal user-facing error,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #9 from Peter Bergner ---
(In reply to Kewen Lin from comment #8)
> I noticed even without -fno-omit-frame-pointer, the test case still fails
> with the same symptom (with error msg rather than ICE), did I miss something?
With no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #7 from Peter Bergner ---
(In reply to Andrew Pinski from comment #6)
> Pre-IRA fix was done to specifically reject this:
> https://inbox.sourceware.org/gcc-patches/
> ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #4 from Peter Bergner ---
(In reply to Andrew Pinski from comment #3)
> Well I am going to say this about the code in that repo, the inline-asm in
> slp_switch looks very broken anyways.
100% agree, but broken for other reasons. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Peter Bergner changed:
What|Removed |Added
CC||doko at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #2 from Peter Bergner ---
CC'ing some architecture and RA experts for their input.
I believe the riscv64 test showing the same issue would be:
void
bug (void)
{
__asm__ volatile ("" : : : "s0");
}
...but I don't have a cross
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Current builds of the greenlet package on one specific distro, are seeing an
ICE on multiple architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #11 from Peter Bergner ---
(In reply to Sam James from comment #10)
> No problems reported yet and we have several people testing on ppc w/ gcc 14.
Thanks for the testing! This is clearly a stage1 patch, so we'll wait until
then
at gcc dot gnu.org|bergner at gcc dot
gnu.org
URL||https://gcc.gnu.org/piperma
||il/gcc-patches/2022-Septemb
||er/601825.html
--- Comment #17 from Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #22 from Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
--- Comment #4 from Peter Bergner ---
The bogus vsx_splat_ code goes all the way back to GCC 8, so we need
backports to the open release branches (GCC 13, 12, 11).
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=54284
Peter Bergner changed:
What|Removed |Added
CC|bergner at vnet dot ibm.com, |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50329
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
||bergner at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #4)
> We now do
>
> cntlzw 3,3
> srwi 3,3,5
> xori 3,3,0x1
>
|RESOLVED
CC||bergner at gcc dot gnu.org
--- Comment #5 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #4)
> Still happens.
I'm marking this as WONTFIX since -mminimal-toc is an option that is basically
never u
||bergner at gcc dot gnu.org
Status|REOPENED|RESOLVED
--- Comment #7 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #6)
> Actually, huh, *not* fixed on trunk yet.
This was fixed in GCC 13. Marking it as FIXED.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
CC||aagarwa at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #31 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #30)
> Either tree parmdef = ssa_default_def (cfun, parm) is NULL, or has_zero_uses
> (parmdef).
> Not sure if has_zero_uses will work properly after some bbs are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284
--- Comment #9 from Peter Bergner ---
(In reply to GCC Commits from comment #8)
> The master branch has been updated by Ilya Leoshkevich :
Bill, can you double check our testsuite results and close this if it's now
fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113728
--- Comment #3 from Peter Bergner ---
(In reply to Florian Weimer from comment #2)
> This has been worked around in glibc. Should we close this issue?
As the bug reporter and given glibc now has a workaround, I think you're fine
to close this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #29 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #28)
> Yes, so it is the backend that told function.cc that there is a parameter
> save area and it should be adding REG_EQUIV notes. So, the idea would be
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #27 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #26)
> But I still think the workaround is possible on the callee side.
> Sure, if the DECL_HIDDEN_STRING_LENGTH argument(s) is(are) used in the
> function, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #24 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #23)
> if the PowerPC backend maintainers wanted, there could be a similar workaround
> on the rs6000 backend side, in the decisions whether the callee can use
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Peter Bergner changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We emit a superfluous rldicl insn for the following test case. The rlwinm is
all that is needed/required. This is not a regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
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=112103
--- Comment #5 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #4)
> So, let's just adjust the testcase then?
We still want to remove the superfluous instruction, but that should be covered
in a separate bug. So yeah, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-02-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> In all those cases the code is perfectly fine, but also in all of those
> cases the
> code is still suboptimal: the rldicl is just as superfluous as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
--- Comment #8 from Peter Bergner ---
...unless the other P9 systems that were tested built with those "broken"
versions of the compilers. If that's the case, then it points to something
else wrong on that system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #6 from Peter Bergner ---
(In reply to GCC Commits from comment #5)
> commit r14-7270-g39fa71a0882928a25bd170580e3e9e89a69dce36
> Author: Kewen Lin
> Date: Mon Jan 15 20:55:40 2024 -0600
>
> testsuite: Fix vect_long_mult on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
--- Comment #7 from Peter Bergner ---
(In reply to seurer from comment #6)
> I tried an older compiler (8.4) and it worked ok.
>
> I just experimented a bit and it fails with the current gcc 11 and 12 used
> as the build compiler as well. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
--- Comment #1 from Peter Bergner ---
(In reply to seurer from comment #0)
> g:1413af02d62182bc1e19698aaa4dae406f8f13bf, r14-7033-g1413af02d62182
>
> Note I only saw this failure on one powerpc64 LE system. It works OK on
> others.
You tend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112886
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
--- Comment #5 from Peter Bergner ---
(In reply to Kewen Lin from comment #4)
> Yes, I agree it's duplicated of PR109987, Jeevitha's commit just exposed
> this known issue, since we are in stage 3, I wonder if we can go with
> power9-vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The following testcase has a bogus warning on trunk back to at least gcc 11.
bergner@ltcden2-lp1:LTC193379$ cat bug.c
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #8 from Peter Bergner ---
(In reply to Peter Bergner from comment #7)
> This fixes the ICE on the large original test case and the smaller test
> cases. I'll bootstrap and regtest it and report back on the results.
I did a normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #7 from Peter Bergner ---
(In reply to Martin Jambor from comment #5)
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index 3bd0c7a9af0..99a1b0a6d17 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -4219,11 +4219,15 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #6 from Peter Bergner ---
(In reply to Martin Jambor from comment #5)
> The following should fix it. I'll try a bit more to come up with a testcase
> that would not require __builtin_vec_vsx_st but so far my simple attempts
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #5 from Peter Bergner ---
(In reply to Richard Biener from comment #3)
> Can't we make sure to pass -mno-any (if that exists...) during bootstrap
> and testsuite instead?
-mno-any does not exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2023-12-05
Ever confirmed|0
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Since commit r10-580-ge154242724b084 gcc no longer passes -many to the
assembler for --enable-checking=yes builds. However, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #14 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Peter Bergner from comment #12)
> > I'll note that you don't always
> > get an assembler error, since gcc still passes -many to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #11 from Peter Bergner ---
(In reply to Kewen Lin from comment #10)
> (In reply to HaoChen Gui from comment #9)
>
>> My question is: can "fctid" be executed on powerpc7450 such a 32bit
>> processor? If it's supported, should the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #3 from Peter Bergner ---
Created attachment 56784
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56784=edit
creduce minimized test case
Attached creduce minimized test case. Use -O3 -mcpu=power10 to recreate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2023-12-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #6 from Peter Bergner ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Peter Bergner from comment #4)
> > CCing richi and jakub to see if they've seen anything like this before?
>
> I suspect we are miscompiling the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #6)
> That said, I think nearly all (all?) HTM usage on Power uses our HTM
> built-in functions. Maybe we could remove OPTION_MASK_HTM from the
> power8/power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #6 from Peter Bergner ---
(In reply to Kewen Lin from comment #3)
> The motivation of this request is to try our best to make power10 attributed
> code inline more power8/power9 attribute code which likely includes some
> inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #5 from Peter Bergner ---
(In reply to Jan Wassenberg from comment #4)
> I understand the slippery slope concern. But the empty asm string is a
> special case, we and others use it (with +r output and memory clobber) to
> prevent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #2 from Peter Bergner ---
(In reply to Peter Bergner from comment #1)
> If the user compiles a piece of inline asm that doesn't support the
> features used in that inline asm, then that is user error!
I meant to say: If the user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #9 from Peter Bergner ---
(In reply to CVS Commits from comment #8)
> The master branch has been updated by Vladimir Makarov
> :
>
> https://gcc.gnu.org/g:51ca05031959d3accffe873e87d4bc4fbd22e9e9
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #19 from Peter Bergner ---
(In reply to Rui Ueyama from comment #11)
> I'll try to add a POWER10 support to mold using Qemu.
I noticed some Power10 mold code was committed in March. Does that mean this
is "fixed" in mold now? If
|NEW
Last reconfirmed||2023-09-30
CC||bergner at gcc dot gnu.org,
||dje at gcc dot gnu.org,
||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
Peter Bergner changed:
What|Removed |Added
CC|g...@the-meissners.org |meissner at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111228
--- Comment #8 from Peter Bergner ---
(In reply to CVS Commits from comment #7)
> The master branch has been updated by Peter Bergner :
Bah, wrong PR#, Sorry! :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216
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=111216
--- Comment #3 from Peter Bergner ---
(In reply to Peter Bergner from comment #2)
> The code change that led to this looks correct to me. Are we possibly just
> folding more than we used to (a good thing), and that is changing our
> numbers?
1 - 100 of 1380 matches
Mail list logo
