[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
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 not support the DARN insn? Or have a faulty DARN?
You can check the AT_HWCAP2 value for whether your system has darn enabled or
not. I'll note darm was added in Power9, so __builtin_cpu_supports("darn")
should be false for Power8.
On my Power10 system, I see:
bergner@ltcden2-lp1:~$ LD_SHOW_AUXV=1 /bin/true | grep HWCAP2
AT_HWCAP2:mma arch_3_1 scv darn ieee128 arch_3_00 vcrypto tar isel
ebb dscr arch_2_07
(In reply to seurer from comment #5)
> BTW, I tried various changes in configure options, build compilers,
> binutils, and such in case something there was an issue but it always fails
> on just this one power 8 system. It works fine on another similar power 8
> and other power X (X!=8) systems.
Bill, which Power8 system is it that we're seeing this on?
Can you determine which test0*() function is the one having the issue?
[Bug libstdc++/109889] [13/14/15 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||jeevitha at gcc dot gnu.org --- Comment #15 from Peter Bergner --- Jeevitha, can you try and recreate the failure and track down what is happening? Thanks.
[Bug libstdc++/114742] invalid use of '__ieee128' in and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Peter Bergner --- Adding Mike and Segher to correct me if I'm wrong on anything... :-) The canonical method for determining whether a specific cpu has VSX enabled or not is checking for "#if defined(_ARCH_PWR*) && defined(__VSX__)". I believe we're trying to move away from testing things like "__POWER8_VECTOR__". I seem to be blanking on the minimum cpu required for __ieee128, so I'll let Mike or Segher comment on that. I thought is was Power7, which would mean using _ARCH_PWR7 above, but given -mcpu=power7 still fails, maybe Power8 is the minimum needed for __ieee128 support? Mike and Segher???
[Bug tree-optimization/116546] New: Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546
Bug ID: 116546
Summary: Missed optimization of redundant comparison
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 potential values to [0,7].
The "n >= 4" test further narrows its potential values to [4,7], making the "n
& 4" test always true, allowing the elimination of the code path calling bar().
bergner@ltcden2-lp1:~$ cat test.c
extern long foo (void);
extern long bar (void);
long
test (long n)
{
n &= 7;
if (n >= 4) {
if (n & 4)
return foo ();
else
return bar ();
}
return 0;
}
Current gcc (-O2) does optimize this on powerpc64le-linux and removes the bar()
code path. However, if we change the "n >= 4" test to either "n > 4" or "n ==
4", then we fail to eliminate the code path to bar(), even though the "n & 4"
test remains redundant.
Using -O2 -mcpu=power10 (-mcpu=power10 allows tail calls making the resulting
asm easier to read, but it isn't required) produces for the "n >= 4" test:
test:
andi. 3,3,0x4
bne 0,.L4
li 3,0
blr
.p2align 4,,15
.L4:
b foo@notoc
Where as the "n > 4" test results in:
test:
rldicl 2,3,0,61
cmpdi 0,2,4
ble 0,.L2
andi. 3,3,0x4
beq 0,.L3
b foo@notoc
.p2align 4,,15
.L2:
li 3,0
blr
.p2align 4,,15
.L3:
b bar@notoc
Interestingly to me, the optimized code keeps the inner redundant "n & 4" test
(andi. 3,3,0x4) and removes the outer tests. I didn't expect that.
[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
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 backporting it to the release branches.
[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-August/ ||661037.html --- Comment #7 from Peter Bergner --- Patch submitted.
[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
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 that should have
> the same special handling that TImode has, but doesn't. The simple fix
> fixes the attached test case for me and PASSes all of the swap-p8-*.c
> testsuite test cases. My full bootstrap and regtesting is running.
FYI, here is the fix that survived bootstrap and regtesting with no regressions
which I'll submit.
diff --git a/gcc/config/rs6000/rs6000-p8swap.cc
b/gcc/config/rs6000/rs6000-p8swap.cc
index 639f477d782..15e44bb63a6 100644
--- a/gcc/config/rs6000/rs6000-p8swap.cc
+++ b/gcc/config/rs6000/rs6000-p8swap.cc
@@ -2469,10 +2469,11 @@ rs6000_analyze_swaps (function *fun)
mode = V4SImode;
}
- if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
+ if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
+ || mode == PTImode)
{
insn_entry[uid].is_relevant = 1;
- if (mode == TImode || mode == V1TImode
+ if (mode == TImode || mode == PTImode || mode == V1TImode
|| FLOAT128_VECTOR_P (mode))
insn_entry[uid].is_128_int = 1;
if (DF_REF_INSN_INFO (mention))
@@ -2497,10 +2498,11 @@ rs6000_analyze_swaps (function *fun)
&& ALTIVEC_OR_VSX_VECTOR_MODE (GET_MODE (SET_DEST (insn
mode = GET_MODE (SET_DEST (insn));
- if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
+ if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
+ || mode == PTImode)
{
insn_entry[uid].is_relevant = 1;
- if (mode == TImode || mode == V1TImode
+ if (mode == TImode || mode == PTImode || mode == V1TImode
|| FLOAT128_VECTOR_P (mode))
insn_entry[uid].is_128_int = 1;
if (DF_REF_INSN_INFO (mention))
[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Peter Bergner --- (In reply to Peter Bergner from comment #1) > I suspect that this related to our Power8 swap optimization pass. 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 that should have the same special handling that TImode has, but doesn't. The simple fix fixes the attached test case for me and PASSes all of the swap-p8-*.c testsuite test cases. My full bootstrap and regtesting is running.
[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
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;
Value value;
static inline void
foo (const uint64_t delta1, const uint64_t delta2)
{
Value cur;
cur.raw_data = value.raw_data;
for (;;) {
Value next;
next.t.a = cur.t.a+delta1;
next.t.b = cur.t.b+delta2;
if (__atomic_compare_exchange(&value.raw_data, &cur.raw_data,
&next.raw_data, 0, __ATOMIC_SEQ_CST, __ATOMIC_ACQUIRE)) break;
}
}
int
main (void)
{
foo (1, 2);
printf ("%lu %lu\n", value.t.a, value.t.b);
return 0;
}
bergner@ltcden2-lp1:BUG$ gcc -O2 -mcpu=power8 -mno-optimize-swaps bug.c
bergner@ltcden2-lp1:BUG$ ./a.out
1 2
bergner@ltcden2-lp1:BUG$ gcc -O2 -mcpu=power8 -moptimize-swaps bug.c
bergner@ltcden2-lp1:BUG$ ./a.out
2 1
[Bug target/116415] [13 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
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 --- Comment #3 from Peter Bergner --- I'm having a look.
[Bug target/116415] [13 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415 Peter Bergner changed: What|Removed |Added Component|tree-optimization |target --- Comment #2 from Peter Bergner --- (In reply to Peter Bergner from comment #1) > I suspect that this related to our Power8 swap optimization pass. Also confirmed. Adding -mno-optimize-swaps to the options gives us correct results.
[Bug tree-optimization/116415] [13 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail||12.0, 13.0, 14.0, 15.0
Last reconfirmed||2024-08-19
Target||powerpc64le-linux
Known to work||11.0
Ever confirmed|0 |1
--- Comment #1 from Peter Bergner ---
Confirmed. I see this working on gcc11 and fails for gcc12 and later. This
also requires -mcpu=power8. It passes with -mcpu={power9,10}.
I suspect that this related to our Power8 swap optimization pass.
[Bug target/116030] ICE "could not split insn" in final_scan_insn_1, at final.cc on power pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-08-16
Ever confirmed|0 |1
CC||bergner at gcc dot gnu.org,
||guihaoc at gcc dot gnu.org,
||linkw at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #1 from Peter Bergner ---
Confirmed, although on my native build, I had to add either -mcpu=power8 or
-mcpu=power7. It passes for me for -mcpu=power6 or earlier and
-mcpu={power9,power10}.
Haochen, this isn't related (fixed?) by some of your recent patches dealing
with const vector 0 sources, is it?
[Bug target/109329] rs6000: New testcases {mul,div}ic3* should run on systems without QP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329 Peter Bergner changed: What|Removed |Added Last reconfirmed||2024-08-14 CC||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Peter Bergner --- (In reply to Jeevitha from comment #1) > This test case requires a Power7 or above due to the ieeelongdouble ABI. > The test case includes "ppc_float128_sw", but this is not helpful. We can > use the target check "ppc_ieee128_ok" to verify IEEE support. It's "unhelpful" since the ppc_float128_sw test adds -mvsx to the test case fragment and we currently have a bug in the rs6000 backend where -mvsx incorrectly silently enables Power7 code generation, rather than flagging an error on -mcpu=XXX compiles where XXX is older than Power7, making us execute the test case when we shouldn't be. Mike has patches submitted and not yet reviewed that is supposed to "fix" that. That being said, I think ppc_ieee128_ok is still the correct test to use here, since the test case is using -mabi=ieeelongdouble. That will correctly disable the test on pre-Power7 cpus even today. Yes, the test case only has complex ibmdoubledouble code usage, since it explicitly uses -mabi=ieeelongdouble on the command line and when we process options, we cannot know there is no actual ieee128 code usage, we have to flag an error for pre-Power7 cpus. So Segher, I assume you mean these test cases should be run on P7 and later compiles, but not earlier than Power7, correct?
[Bug target/116266] rs6000: P10 vector insn ICE with -mno-vsx
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 P9 vector support respectively, we should have a similar > TARGET_P10_VECTOR which can be TARGET_POWER10 && TARGET_VSX underlying, also > need enum bif_enable ENB_P10V and so on. I agree that's an oversight and we need TARGET_P10_VECTOR.
[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'
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 in my actual configure command, so yes, it works with it spelled correctly.
[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'
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 instead or what? I don't know. :-). Hopefully Mike can answer, since he knows the TF/IF/KFmode support on Power better than anyone. That said... (In reply to Jakub Jelinek from comment #15) > If so, then perhaps > --- libquadmath/math/sqrtq.c.jj 2024-04-09 08:16:54.128737859 +0200 > +++ libquadmath/math/sqrtq.c 2024-08-02 23:28:00.862495012 +0200 > @@ -9,6 +9,9 @@ > && defined(FE_TOWARDZERO) \ > && defined(FE_INEXACT) > #define USE_SOFT_FP 1 > +#if defined(_ARCH_PPC) && !defined(__LONG_DOUBLE_IEEE128__) > +#define TFtype __float128 > +#endif > #include "../../libgcc/soft-fp/soft-fp.h" > #include "../../libgcc/soft-fp/quad.h" > #endif > would fix that. I applied that patch and my powerpc64le-linux --without-lond-double-128 build completed with no errors. Whether what it produced is correct or not, I'll leave to Mike to answer.
[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-08-02 Ever confirmed|0 |1 --- Comment #13 from Peter Bergner --- Just as an FYI, the following error on a powerpc64le-linux --without-long-double-128 build: In file included from ../../../libquadmath/math/sqrtq.c:13: ../../../libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF' 69 | typedef float TFtype __attribute__ ((mode (TF))); | ^~~ ...first shows up with the following commit: commit 481ba4fb5fce8257f5dbeb994dac2748c0237fa2 (HEAD) Author: Jakub Jelinek AuthorDate: Tue Apr 9 08:17:25 2024 +0200 Commit: Jakub Jelinek CommitDate: Tue Apr 9 08:17:25 2024 +0200 libquadmath: Use soft-fp for sqrtq finite positive arguments [PR114623] sqrt should be 0.5ulp precise, but the current implementation is less precise than that. The following patch uses the soft-fp code (like e.g. glibc for x86) for it if possible. I didn't want to replicate the libgcc infrastructure for choosing the right sfp-machine.h, so the patch just uses a single generic implementation. As the code is used solely for the finite positive arguments, it shouldn't generate NaNs (so the exact form of canonical QNaN/SNaN is irrelevant), and sqrt for these shouldn't produce underflows/overflows either, for < 1.0 arguments it always returns larger values than the argument and for > 1.0 smaller values than the argument. 2024-04-09 Jakub Jelinek PR libquadmath/114623 * sfp-machine.h: New file. * math/sqrtq.c: Include from libgcc/soft-fp also soft-fp.h and quad.h if possible. (USE_SOFT_FP): Define in that case. (sqrtq): Use soft-fp based implementation for the finite positive arguments if possible. ...which is due to the above commit code includes quad.h, and quad.h (even before the above commit) seems to require TFmode exists, which it doesn't on a --without-long-double-128 build.
[Bug other/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently
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 be intermittent. I would expect if we pass the same objects to the linker, the result should 100% be the same every time.
[Bug testsuite/116061] [15 regression] new test case gcc.dg/pr116034.c from r15-2220-gb9cefd67a2a464 fails execution on BE
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.
[Bug testsuite/116061] [15 regression] new test case gcc.dg/pr116034.c from r15-2220-gb9cefd67a2a464 fails execution on BE
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?
[Bug testsuite/116061] [15 regression] new test case gcc.dg/pr116034.c from r15-2220-gb9cefd67a2a464 fails execution on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061 Peter Bergner changed: What|Removed |Added CC||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-07-24 --- Comment #1 from Peter Bergner --- Compiling the test case on BE, I see the following asm: li 9,256 addis 10,2,.LANCHOR0@toc@ha sth 9,.LANCHOR0@toc@l(10) lwz 9,.LANCHOR0@toc@l(10) cmpwi 0,9,256 ... Clearly, storing a halfword to mem and then loading it as a word and expecting them to be the same isn't likely to work.
[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Peter Bergner --- Fixed everywhere.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Peter Bergner --- Fixed everywhere.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
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 backports.
[Bug target/103548] Identical MMA assemble quads are incorrectly combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103548 Peter Bergner changed: What|Removed |Added Known to fail|12.0| Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Peter Bergner --- This is fixed in GCC 12 and later and won't make GCC 11, so marking this as fixed.
[Bug testsuite/115988] New test case gcc.target/powerpc/pr114759-3.c from r15-2081-g6f2bab9b5d1ce1 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Peter Bergner --- Fixed.
[Bug testsuite/115988] New test case gcc.target/powerpc/pr114759-3.c from r15-2081-g6f2bab9b5d1ce1 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-July/65 ||7729.html --- Comment #2 from Peter Bergner --- Submitted obvious fix.
[Bug testsuite/115988] New test case gcc.target/powerpc/pr114759-3.c from r15-2081-g6f2bab9b5d1ce1 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||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.
[Bug target/107181] [13 regression] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Peter Bergner --- (In reply to Sam James from comment #7) > Adjusting title out of pedantry but I suspect it's fixed and was never > broken for 14/15 as a result. Looking through Bill's recent powerpc64-linux testsuite results posts, I don't see this test case FAILing, so I'm going to close this as fixed and Bill can reopen if I somehow missed a FAIL for a particular BE target.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned 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.
[Bug target/107181] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #5 from Peter Bergner --- (In reply to Cupertino Miranda from comment #4) > Just would like to mention that I have been working on this and will soon > submit some patches for review. Is this still a problem? Was a patch submitted and committed and we just forgot to close this bug?
[Bug target/108220] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Peter Bergner --- Fixed by the patch for PR112340.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |15.0 URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2024-June/65 |il/gcc-patches/2024-July/65 |4217.html |7184.html Status|UNCONFIRMED |NEW Last reconfirmed||2024-07-12 --- Comment #9 from Peter Bergner --- I posted an updated version of the latest patch that incorporates the review comments plus an additional code change from myself.
[Bug target/110040] rs6000 port emits dead mfvsrd instruction for simple test case
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 from Peter Bergner --- Kewen and Segher, is this something we want backported or just call it good and close as FIXED? I ask since the patch just adds a simple splitter which doesn't look too dangerous.
[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute
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 expected to see warning like:
>
> warning: ‘-mvsx’ and ‘-mno-altivec’ are incompatible
I think Segher and I mentioned in the other bug, that conflicting options like
this should be an error, rather than a warning.
[Bug target/115688] [15 regression] ICE on simple test case from r15-703-gb390b011569635
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-altivec,vsx")))
> > foo (void)
> > {
> > return 0;
> > }
>
> It should hard error for it. That combination is not valid. VSX requires
> VMX.
Agreed. I think all invalid option combinations should be hard errors.
> -mabi={no-,}altivec is only for the 32-bit ABIs. All the 64-bit ABIs had
> either only compatible changes to support VMX, or only ever had support for
> it in the first place.
In that case, -mabi=no-altivec should also be a hard error if -m64 is in
effect.
[Bug target/115688] [15 regression] ICE on simple test case from r15-703-gb390b011569635
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 for 64-bit as well, both BE and LE with the following
options:
bergner@ltcden2-lp1:ICE$ gcc -S -m64 -O2 -mcpu=power5 -mabi=no-altivec bug.c
bug.c:3:1: internal compiler error: in rs6000_option_override_internal, at
config/rs6000/rs6000.cc:3952
3 | {
| ^
0x11e4f7a7 rs6000_option_override_internal
/home/bergner/gcc/gcc-fsf-mainline-rop/gcc/config/rs6000/rs6000.cc:3952
0x11eb7f13 rs6000_valid_attribute_p
/home/bergner/gcc/gcc-fsf-mainline-rop/gcc/config/rs6000/rs6000.cc:24809
0x10aace97 handle_target_attribute
/home/bergner/gcc/gcc-fsf-mainline-rop/gcc/c-family/c-attribs.cc:5915
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index cd14e5a34ed..a8a3b79dda0 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -3925,8 +3925,12 @@ rs6000_option_override_internal (bool global_init_p)
> not for 32-bit. Don't move this before the above code using
> ignore_masks,
> since it can reset the cleared VSX/ALTIVEC flag again. */
>if (main_target_opt && !main_target_opt->x_rs6000_altivec_abi)
> -rs6000_isa_flags &= ~((OPTION_MASK_VSX | OPTION_MASK_ALTIVEC)
> - & ~rs6000_isa_flags_explicit);
> +{
> + rs6000_isa_flags &= ~(OPTION_MASK_VSX & ~rs6000_isa_flags_explicit);
Given this...
> + /* Don't mask off ALTIVEC if it is enabled by an explicit VSX. */
> + if (!TARGET_VSX || !(rs6000_isa_flags_explicit & OPTION_MASK_VSX))
TARGET_VSX is only true here if it was explictly used, so I think you can drop
the "|| !(rs6000_isa_flags_explicit & OPTION_MASK_VSX)" part of this test.
That said, how does your patch handle the following test case?
long __attribute__ ((target ("no-altivec,vsx")))
foo (void)
{
return 0;
}
...currently, this compiles with with no error or warning message which seems
wrong to me.
[Bug target/115688] ICE on simple test case from r15-703-gb390b011569635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688 Peter Bergner changed: What|Removed |Added Last reconfirmed||2024-06-27 CC||linkw at gcc dot gnu.org, ||segher at gcc dot gnu.org Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Target||powerpc-linux Ever confirmed|0 |1
[Bug target/115688] New: ICE on simple test case from r15-703-gb390b011569635
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
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 looks like (ICEs for power4/5/6 and does not ICE for power7 and later):
bergner@nilram:ICE$ cat ice.c
long __attribute__ ((target ("vsx")))
foo (void)
{
return 0;
}
bergner@nilram:ICE$ gcc -S -m32 -O2 -mcpu=power5 -mno-vsx ice.c
ice.c:3:1: internal compiler error: in rs6000_option_override_internal, at
config/rs6000/rs6000.cc:3945
3 | {
| ^
0x11e208d7 rs6000_option_override_internal
/home/bergner/gcc/gcc-fsf-mainline-rop-base/gcc/config/rs6000/rs6000.cc:3945
0x11e8ba57 rs6000_valid_attribute_p
/home/bergner/gcc/gcc-fsf-mainline-rop-base/gcc/config/rs6000/rs6000.cc:24802
0x10abbe0b handle_target_attribute
/home/bergner/gcc/gcc-fsf-mainline-rop-base/gcc/c-family/c-attribs.cc:5915
...
[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
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 > > > backporting this? > > > > For code correctness bugs, yes, we want them backported. > > Thanks for confirming! Will do backporting after burn-in time. Have we done the backports so we can just mark this bug a FIXED? ...or do we still need to push the backports?
[Bug target/114759] Power: multiple issues with -mrop-protect
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
[Bug target/114759] Power: multiple issues with -mrop-protect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||5028.html --- Comment #6 from Peter Bergner --- Updated patch for item 2. submitted.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
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 "fixing" that as part of my PR114759 work.
[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec
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.
[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||15.0 --- Comment #5 from Peter Bergner --- Fixed.
[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4397.html Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org
[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec
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 the offset must be a multiple of 8. The "bug" is that we initialize rop_hash_save_offset to zero very early, before any option processing. Later, we compute the actual offset, but only in the case where Altivec is enabled (TARGET_ALTIVEC_ABI is true). If Altivec is disabled as in this test case, we end up using rop_hash_save_offset's invalid initial zero value.
[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1
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 really judge if the new code is better, worse is equivalent. xxsel XT,XA,XB,XC computes XT = (XA & ~XC) | (XB & XC). Using De Morgan's law given XB == XC, that seems to simplify to XT = XA | XB which is what you're producing and an xxlor (a simple logical or) is not going to be slower than a xxsel and is probably faster. I agree with Bill that this looks like an example of needing to update the expected results of the test case. I'll let Segher and/or Ke Wen comment though.
[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec
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 Target||powerpc64le-linux Ever confirmed|0 |1 Last reconfirmed||2024-06-07 CC||linkw at gcc dot gnu.org, ||segher at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Peter Bergner --- I have a patch I'm testing.
[Bug target/115389] New: Invalid ROP hashst offset is emitted when using -mabi=no-altivec
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
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
extern void foo (void);
long
bar (void)
{
foo ();
return 0;
}
bergner@ltcd97-lp3:~/ROP$ gcc -c -O2 -mcpu=power10 -mrop-protect -mno-vsx
-mno-altivec -mabi=altivec bug.c
bergner@ltcd97-lp3:~/ROP$ gcc -c -O2 -mcpu=power10 -mrop-protect -mno-vsx
-mno-altivec -mabi=no-altivec bug.c
/tmp/ccSzxbv5.s: Assembler messages:
/tmp/ccSzxbv5.s:15: Error: invalid offset: must be in the range [-512, -8] and
be a multiple of 8
/tmp/ccSzxbv5.s:25: Error: invalid offset: must be in the range [-512, -8] and
be a multiple of 8
The bug is we only compute the ROP hash save slot offset when
TARGET_ALTIVEC_ABI is true. If TARGET_ALTIVEC_ABI is false and we enable ROP
mitigation, then we use the initialized value of zero which is an illegal
offset value for hashst and hashchk.
This has been broken since the rs6000 ROP mitigation code was first added, so
not a regression.
[Bug target/115355] [12/13/14/15 Regression] PPCLE: Auto-vectorization creates wrong code for Power9
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 do no vectorize the loop. We vectorize the loop when using unsigned int/short/char. The vectorized code is a little strange, in that the smaller the integer type we use for the index var, the more code we generate. The vectorized code for unsigned char is truly huge! ...although it does seem to work correctly. I'm attaching the "unsigned char i" code gen for setToIdentityBAD for people to examine. Even though it gives "correct" results, it can't really be the code we want to generate, correct???
[Bug target/115355] [12/13/14/15 Regression] PPCLE: Auto-vectorization creates wrong code for Power9
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.
[Bug target/115355] PPCLE: Auto-vectorization creates wrong code for Power9
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.
[Bug target/115355] PPCLE: Auto-vectorization creates wrong code for Power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Peter Bergner --- I'll find someone to look into this. Thanks for the test case!
[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
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.
[Bug target/113652] [14/15 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
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=power10 (and in the future --with-cpu=power11 or > --with-cpu=future). This could be code that if __VSX__ is not defined, the > libgcc support functions won't get built. We would then remove the -mvsx > option from the library support functions. I think this is the solution we want, meaning if the target we're building supports VSX, then we'll build the IEEE128 bits, otherwise, we won't build them. I think that is the only sane answer. I also believe that if the user specifies a -mcpu= option (either implicitly or explicitly) that doesn't support VSX (eg, power4, or 7450, etc.) and they also explicitly use -mvsx, then we should emit an error message saying the -mcpu= option doesn't support using -mvsx at the same time. Ditto for -maltivec, -mmma, etc. We should not be silently enabling instruction support over and above their -mcpu= selection just because its needed for VSX/Altivec/MMA/etc. support. Currently we don't emit an error and instead silently enable generating instructions not supported by their -mcpu= option.
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
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/develop.html#timeline, gcc-14 stage1 ended several > months ago), it will have to wait for gcc-15? Correct, I meant waiting for GCC 15 stage1. I want it to burn-in on trunk for a long while, because it had the potential to disrupt distro package builds. It seems clean so far with the practice Gentoo builds, but I'll feel more comfortable when other distros start using it too. That said, Jeevitha, now that we're in stage1, can you please post your patch?
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #28 from Peter Bergner --- Fixed everywhere.
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345 Peter Bergner changed: What|Removed |Added Depends on||101129 --- Comment #4 from Peter Bergner --- (In reply to Jeevitha from comment #3) > The commit that resolved the incorrect code was > ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for > mult with subreg. This addressed the issue. Ok, so that was the fix for PR101129. Thanks for tracking that down Jeevitha! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 [Bug 101129] [11/12 Regression] wrong code at -O1 since r11-5839
[Bug target/101345] wrong code at -O1 with vector modulo
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 -mcpu=power8 for my compiles.
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.0, 14.0 CC||jeevitha at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Last reconfirmed||2024-4-18 --- Comment #1 from Peter Bergner --- I can confirm the checkout used at the time (b019b28ebd65462a092c96d95e9e356c8bb39b78) does produce "subfic rX,rX,4". That said, with commit b85e79dce149df68b92ef63ca2a40ff1dfa61396 (about the time gcc13 branches), it is fixed to "subfic rX,rX,2", so I'm marking this as RESOLVED/FIXED. It remains fixed since that commit too. Jeevitha, can you please do a git bisect from the two commits above to identify the commit that fixes this for posterity sake? Thanks.
[Bug target/114759] Power: multiple issues with -mrop-protect
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 error().
Like so:
- /* If we are inserting ROP-protect instructions, disable shrink wrap. */
+
if (rs6000_rop_protect)
-flag_shrink_wrap = 0;
+{
+ if (!TARGET_POWER8 || DEFAULT_ABI != ABI_ELFv2)
+ rs6000_rop_protect = 0;
+ else
+ /* If we are inserting ROP-protect instructions, disable shrink wrap.
*/
+ flag_shrink_wrap = 0;
+}
[Bug target/114759] Power: multiple issues with -mrop-protect
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 combinations (currently assuming P7 and earlier are invalid) as an error. 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 error().
[Bug target/114759] Power: multiple issues with -mrop-protect
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. What we do now is: gcc -dM -E -mcpu=power10 test.c | grep ROP gcc -dM -E -mcpu=power10 -mrop-protect test.c | grep ROP #define __ROP_PROTECT__ 1 gcc -dM -E -mcpu=power4 -mrop-protect test.c | grep ROP #define __ROP_PROTECT__ 1 ...and that last compile is a wrong code bug. If we want to continue to silently disable ROP protection with -mcpu=power4, then we also need to not define __ROP_PROTECT__. If we decide we want an error for this, which I mentioned later as an solution, then this is fixed automatically by doing that. > If you want to refuse the option without a -mcpu= that can generate useful > code for it, that's fine, but that is not what we do. Instead, we generate > code that will do the ROP-protection boogaloo on CPUs that implement support > for that, and does nothing otherwise. We do not currently do "nothing" when we see -mcpu=power4 -mrop-protect. Yes, we do not emit the hashst and hashchk insns, but we *do* emit the __ROP_PROTECT__ predefined macro and that is bad. The most common usage of that macro is in .S assembler files and if we define __ROP_PROTECT__ in the wrong cases, they can end up with assembler errors. Again, if we decide to emit an error for -mcpu=power4 -mrop-protect, then this is just fixed automatically. >> 2. We always disable shrink-wrapping when -mrop-protect is used, [...] > > Yes, this is problematic, and seems to be completely unnecessary. For the case where we silently ignore -mcpu=power4 -mrop-protect, it is completely unnecessary. If we decide to emit an error for this instead, then like the above, this is just automatically fixed. > By exactly the same argument we should *also* do ROP-protection in all > leaf functions, btw! I'm not 100% convinced we need to "protect" leaf functions, since the return address of the leaf function ever makes it onto the stack to be potentially corrupted. Can you explain how a leaf-function could be attacked if we never save its return address to the stack? >> 3. We silently disable ROP protection for everything other than >> -mcpu=power10. The binutils assembler accepts the ROP insns back >> to Power8, so we should emit them for Power8 and later. > > The ISA claims it will work for anything after ISA 2.04, even. True, but given the binutils assembler doesn't accept hashst and hashchk for anything before Power8, it seemed convenient to match that behavior. If we enable it for ISA 2.04 and later, then we either have to fix binutils to do the same (which we can do), but we still run the risk of some compiles failing because the user is using an older unfixed assembler. >> 4. We give an error when -mrop-protect is used with any -mabi=ABI >> value not equal to ELFv2, [...] > > Yes, we should make it work everywhere. Even on -m32. But it requires > adjusting the ABI as well! That's a nice goal, but I'd like to fix the present issues before tackling expanding its use to other ABIs. So the first question to ask is, do we want to silently disable (maybe with a warning) emitting ROP instructions if used with -mcpu=CPU or -mabi=ABI that we don't want or can't emit them for? ...or do we want to produce an error? The answer to this question will help guide us on how to fix the other issues or whether we even have to do anything for them.
[Bug target/114759] Power: multiple issues with -mrop-protect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759 Peter Bergner changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||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 reconfirmed||2024-04-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Confirmed.
[Bug target/114759] New: Power: multiple issues with -mrop-protect
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: 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 when we've silently disabled ROP protection because of a too old -mcpu=CPU value. We should only emit __ROP_PROTECT__ when it's legal to emit the ROP insns. 2. We always disable shrink-wrapping when -mrop-protect is used, even when we've silently disabled ROP protection because of a too old -mcpu=CPU value. We should not disable shrink-wrapping if we've disabled ROP protection. 3. We silently disable ROP protection for everything other than -mcpu=power10. The binutils assembler accepts the ROP insns back to Power8, so we should emit them for Power8 and later. 4. We give an error when -mrop-protect is used with any -mabi=ABI value not equal to ELFv2, whereas a too old -mcpu=CPU value only causes us to silently disable ROP protection. I think both scenarios should behave similarly, so either we silently disable ROP protection for both or we give an error for both. This is not a regression. I consider 1. to be a correctness/wrong code bug.
[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues
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 |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug target/69031] 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 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Peter Bergner --- Maybe already fixed? Marking as resolved for now and we can reopen if someone can actually recreate the ICE. I could not.
[Bug rtl-optimization/96865] ICE in hash_rtx_cb, at cse.c:2548
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 Peter Bergner --- Fails on trunk and basically all earlier versions.
[Bug rtl-optimization/96865] ICE in hash_rtx_cb, at cse.c:2548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug testsuite/114518] [15 regression] gcc.target/powerpc/combine-2-2.c fails after r14-9692-g839bc42772ba7a
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 Status|NEW |ASSIGNED
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
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.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
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 |il/gcc-patches/2022-Septemb |il/gcc-patches/2024-April/6 |er/601825.html |49329.html --- Comment #19 from Peter Bergner --- New patch submitted as an update to Will's patch.
[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698 Peter Bergner changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 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 ... Confirmed that the patch fixes the error. It's too bad the "fix" hasn't been as widely shared. :-( Closing this as INVALID.
[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a
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 to Andrew Pinski from comment #3) > > uint8_t buffer[SHA256_BLOCK_LENGTH]; > > > > W256 = (sha2_word32*)context->buffer; > > > > This is starting to smell like the code is violating strict aliasing rules > > ... > > The patch in https://github.com/NetBSD/pkgsrc/issues/122 applies directly > here too. Thanks for the pointer, I'll try the patch and report back. Jan's commit does seem to make a change in the alias handling, so it very well could have exposed that type of problem in the sha2 routine.
[Bug ipa/114698] dcfldd produces wrong sha256 sum on ppc64le and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698 Peter Bergner changed: What|Removed |Added Component|target |ipa CC||hubicka at gcc dot gnu.org --- Comment #2 from Peter Bergner --- I've confirmed that the function being miscompiled is src/sha2.c:SHA256_Transform() on line 440. I can add configure dcfldd with a normal -O2 and add a __attribute__((optimize (3))) to this function and I see bad output. I can also configure dcfldd with -O3 and add a __attribute__((optimize (2))) to this function and I see good output. Doing a git bisect, it identified the following GCC commit as causing the bug: 64f3e71c302b4a13e61656ee509e7050b9bce978 is the first bad commit commit 64f3e71c302b4a13e61656ee509e7050b9bce978 Author: Jan Hubicka Date: Sun Nov 14 18:49:15 2021 +0100 Extend modref to track kills This patch adds kill tracking to ipa-modref. This is representd by array of accesses to memory locations that are known to be overwritten by the function. gcc/ChangeLog: 2021-11-14 Jan Hubicka * ipa-modref-tree.c (modref_access_node::update_for_kills): New member function. (modref_access_node::merge_for_kills): Likewise. (modref_access_node::insert_kill): Likewise. * ipa-modref-tree.h (modref_access_node::update_for_kills, modref_access_node::merge_for_kills, modref_access_node::insert_kill): Declare. (modref_access_node::useful_for_kill): New member function. * ipa-modref.c (modref_summary::useful_p): Release useless kills. (lto_modref_summary): Add kills. (modref_summary::dump): Dump kills. (record_access): Add mdoref_access_node parameter. (record_access_lto): Likewise. (merge_call_side_effects): Merge kills. (analyze_call): Add ALWAYS_EXECUTED param and pass it around. (struct summary_ptrs): Add always_executed filed. (analyze_load): Update. (analyze_store): Update; record kills. (analyze_stmt): Add always_executed; record kills in clobbers. (analyze_function): Track always_executed. (modref_summaries::duplicate): Duplicate kills. (update_signature): Release kills. * ipa-modref.h (struct modref_summary): Add kills. * tree-ssa-alias.c (alias_stats): Add kill stats. (dump_alias_stats): Dump kill stats. (store_kills_ref_p): Break out from ... (stmt_kills_ref_p): Use it; handle modref info based kills. gcc/testsuite/ChangeLog: 2021-11-14 Jan Hubicka * gcc.dg/tree-ssa/modref-dse-3.c: New test. gcc/ipa-modref-tree.c| 179 +++ gcc/ipa-modref-tree.h| 15 ++ gcc/ipa-modref.c | 126 +--- gcc/ipa-modref.h | 1 + gcc/testsuite/gcc.dg/tree-ssa/modref-dse-3.c | 22 +++ gcc/tree-ssa-alias.c | 207 +++ 6 files changed, 471 insertions(+), 79 deletions(-)
[Bug target/114698] dcfldd produces wrong sha256 sum on ppc64le and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698 Peter Bergner changed: What|Removed |Added Known to work||11.0 CC||dje at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||segher at gcc dot gnu.org Target||powerpc64le-linux Last reconfirmed||2024-04-11 Known to fail||12.0, 13.0, 14.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||wrong-code --- Comment #1 from Peter Bergner --- Confirmed.
[Bug target/114698] New: dcfldd produces wrong sha256 sum on ppc64le and -O3
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 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 produces correct output. For example (-O3 trunk build): bergner@ltcden2-lp1:dcfldd [v1.9.1]$ echo TestInput | ./src/dcfldd hash=sha256 TestInput Total (sha256): d627605bdee37e388a5c232dc407cb5cd287d27187d6787999ad3bb59d383e9a 0+1 records in 0+1 records out ...versus expected output from an -O2 trunk build: bergner@ltcden2-lp1:dcfldd [v1.9.1]$ echo TestInput | ./src/dcfldd hash=sha256 TestInput Total (sha256): 8021973df8498a650e444fd84c705d9168639a246bc6024066e4091b2b450da6 0+1 records in 0+1 records out ...and from sha256sum: bergner@ltcden2-lp1:dcfldd-git [v1.9.1]$ echo TestInput | /usr/bin/sha256sum 8021973df8498a650e444fd84c705d9168639a246bc6024066e4091b2b450da6 - Current steps to recreate: git clone https://github.com/resurrecting-open-source-projects/dcfldd.git cd dcfldd/ git checkout v1.9.1 -b v1.9.1 ./autogen.sh ./configure CFLAGS="-O3" make echo TestInput | ./src/dcfldd hash=sha256
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #15 from Peter Bergner --- (In reply to Richard Sandiford from comment #14) > Yeah, I think so. Ok, then marking as INVALID and greenlet will need to come up with some other solution than the one they're using.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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?
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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, > albeit with bad error recovery, leading us to report the same thing multiple > times. My bad for calling it an ICE. Clearly it's not an ICE but a normal error as you say. > > but how are users supposed to know whether > > -fno-omit-frame-pointer is in effect or not? I've looked and there is no > > pre-defined macro a user could check. > That might be a useful thing to have, but if the programmer has no control > over the build flags (i.e. cannot require/force -fomit-frame-pointer) then I > think the asm has to take care to save and restore the frame pointer itself. > > Dropping "31" from the asm means that the asm must preserve the register. > Things will go badly if the asm doesn't do that. So r31 which we use as our frame-pointer reg is a non-volatile/callee saved register, so it must be saved, but I guess they (greenlet) cannot use the method of mentioning it in the asm clobber list to perform that.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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 option, we default to -fomit-frame-pointer and that option does not guarantee we actually will omit the frame pointer.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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/ Then that would seem to indicate that mentioning the frame pointer reg in the asm clobber list is an error, but how are users supposed to know whether -fno-omit-frame-pointer is in effect or not? I've looked and there is no pre-defined macro a user could check.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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 think still TBD whether the minimal test case here is supposed to work or not.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 Peter Bergner changed: What|Removed |Added CC||doko at gcc dot gnu.org, ||law at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Last reconfirmed||2024-04-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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 compiler right now to verify.
Interestingly, I tried what I thought would be the aarch64 test case
(clobbering x29), but it did not ICE. Did I use the wrong hard frame pointer
register or is aarch64 doing something different here?
[Bug rtl-optimization/114664] New: -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
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
Severity: 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 (ppc64le & riscv64) when being built with
-fno-omit-frame-pointer. The upstream github issue is here:
https://github.com/python-greenlet/greenlet/issues/395
A minimized test case on Power is:
bergner@ltcden2-lp1:$ cat bug.c
void
bug (void)
{
__asm__ volatile ("" : : : "r31");
}
bergner@ltcden2-lp1:$ /opt/gcc-nightly/trunk/bin/gcc -S -fno-omit-frame-pointer
bug.c
bug.c: In function ‘bug’:
bug.c:5:1: error: 31 cannot be used in ‘asm’ here
5 | }
| ^
bug.c:5:1: error: 31 cannot be used in ‘asm’ here
This is not a regression, as all gcc's I have easy access to (back to gcc v8)
ICE the same way.
The code that is ICEing here is in ira.c:ira_setup_eliminable_regset():
/* Build the regset of all eliminable registers and show we can't
use those that we already know won't be eliminated. */
for (i = 0; i < (int) ARRAY_SIZE (eliminables); i++)
{
bool cannot_elim
= (! targetm.can_eliminate (eliminables[i].from, eliminables[i].to)
|| (eliminables[i].to == STACK_POINTER_REGNUM &&
frame_pointer_needed));
if (!TEST_HARD_REG_BIT (crtl->asm_clobbers, eliminables[i].from))
{
SET_HARD_REG_BIT (eliminable_regset, eliminables[i].from);
if (cannot_elim)
SET_HARD_REG_BIT (ira_no_alloc_regs, eliminables[i].from);
}
else if (cannot_elim)
error ("%s cannot be used in % here",
reg_names[eliminables[i].from]);
else
df_set_regs_ever_live (eliminables[i].from, true);
}
On Power, targetm.can_eliminate(r31,r1) returns true (ie, the port will allow
us to eliminate r31 into r1) even in the face of -fno-omit-frame-pointer, but
it's the RA specific test (eliminables[i].to == STACK_POINTER_REGNUM &&
frame_pointer_needed) that is catching us here.
The question I have is, is it legal to mention the hard frame pointer register
in an asm clobber list when using -fno-omit-frame-pointer? Ie, is this user
error or should the compiler be able to handle this?
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
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 before submitting it.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|willschm 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 Bergner --- I'm working on updating the patch Will submitted to take into consideration the patch reviews plus trunk changes since it was submitted. Mine now.
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #22 from Peter Bergner --- I kicked off a 7450 build on one of our BE system and I can confirm we hit this error. I also saw us generating the 2 operand form of the mfcr instruction which also leads to an assembler error because the 7450 doesn't support that either. Were we are in the build is compiling libgcc and the routines for handling KFmode values. The build machinery is explicitly adding -mvsx -mfloat128 to the compiler options when building those source files and that seems bogus to me, since the 7450 does not have VSX hardware. It's the explicit addition of the -mvsx option to the command line that is causing the lfiwzx and 2 operand mfcr instructions to be generated, not some internal mishandling of the -mcpu=7450 option. My $0.02 worth is we should be generating an error when trying to use -msx with -mcpu=7450 or any other cpu that doesn't have VSX hardware. I also don't think we should be building these KFmode files which require VSX when the underlying cpu we're targeting doesn't support it.
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
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).
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
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 from Peter Bergner --- (In reply to Sam James from comment #6) > Please send it to the ML with git-send-email. ...and CC our port maintainers, Segher, Ke Wen and David who are all on CC here.
[Bug target/54284] -mabi=ieeelongdouble problems
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, |dje.gcc at gmail dot com |dje at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Peter Bergner --- I'm pretty sure this has been long ago fixed, so I'm going to close this as FIXED.
[Bug target/50329] [PowerPC] Unnecessary stack frame set up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50329 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Peter Bergner --- (In reply to Segher Boessenkool from comment #2) > Current trunk (to be GCC 6) optimises "c" perfectly. Not the other > two, alas. Current trunk (to be GCC 14) optimizes all of them now. Marking as FIXED. a: li 9,-1 rldicr 9,9,0,0 std 9,0(3) blr b: li 9,-1 rldicr 9,9,0,0 std 9,0(3) blr c: li 9,0 li 10,-1 rldimi 9,10,63,0 std 9,0(3) blr
[Bug target/36557] -m32 -mpowerpc64 produces better code than -m64 for a!=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36557 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED CC||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 > blr > > which is still not optimal (and not what -m32 / -m32 -mpowerpc64 do). My GCC 10 and later compiles show we now generate: addic 9,3,-1 subfe 3,9,3 blr Marking as FIXED.
[Bug target/33236] -mminimal-toc register should be psedu-register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33236 Peter Bergner changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |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 used with the introduction of -mcmodel=medium (and is the default) and which results in ideal code for this testcase.
[Bug target/31557] return 0x80000000UL code gen can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31557 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED CC||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.
[Bug target/101893] There is no vgbbd on p7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #3 from Peter Bergner --- So this looks fixed and we can mark it RESOLVED / FIXED?
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #12 from Peter Bergner --- (In reply to Sergey Fedorov from comment #11) > (In reply to GCC Commits from comment #10) > > The master branch has been updated by Iain D Sandoe : > > Iain, thank you very much for addressing this! If this is fixed for you, can you please move this to RESOLVED / FIXED?
