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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-06-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Bug ID: 115688
Summary: ICE on simple test case from r15-703-gb390b011569635
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
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
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
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]
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
Bug ID: 115389
Summary: Invalid ROP hashst offset is emitted when using
-mabi=no-altivec
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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
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=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,
>
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Bug ID: 114759
Summary: Power: multiple issues with -mrop-protect
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Bug ID: 114698
Summary: dcfldd produces wrong sha256 sum on ppc64le and -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Bug ID: 114664
Summary: -fno-omit-frame-pointer causes an ICE during the build
of the greenlet package
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|willschm
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36557
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33236
Peter Bergner changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31557
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114004
Bug ID: 114004
Summary: GCC emits a superfluous instruction for simple test
case on ppc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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.
1 - 100 of 485 matches
Mail list logo
