[Bug other/81831] New: -Wno-psabi is not documented

Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- The online GCC documentation mentions psABI though out the document, but section "3.8 Options to Request or Suppress Warning" does not describe or even mention -Wno-psabi.

[Bug testsuite/81539] Bad target in new test case gcc.target/powerpc/mmx-packuswb-1.c from r250432

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81539 Steven Munroe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/83402] New: PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- The rs6000/emmintrin.h implementation of _mm_slli_epi32 reports: error: argument 1 must be a 5-bit signed literal

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #1 from Steven Munroe --- Similarly doe _mm_slli_epi64 for any const value > 15 and < 32. So: if (__builtin_constant_p(__B)) { if (__B < 32) lshift = (__v2du) vec_splat_s32(__B);

[Bug c/85830] New: vec_popcntd is improperly defined in altivec.h

Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 44147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44147=edit compile test case for vec_popcntd. Altivec.h should define either the gene

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #4 from Steven Munroe --- Yup this looks like a pasteo from the pi16 implementation which was not caught as P9 was rare at the time. The #if _ARCH_PWR9 clause is an optimization based on better timing for P9 (vs P8) for GPR <-> VSR

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 Steven Munroe changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #7 from Steven Munroe --- Created attachment 43388 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43388=edit correct mmintrin.h for power9 2018-02-09 Steven Munroe * config/rs6000/mmintrin.h

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #9 from Steven Munroe --- Author: munroesj Date: Sun Feb 11 21:45:39 2018 New Revision: 257571 URL: https://gcc.gnu.org/viewcvs?rev=257571=gcc=rev Log: Fix PR 84266 Modified: trunk/gcc/ChangeLog

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #10 from Steven Munroe --- Change this to RESOLVED state now?

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #9 from Steven Munroe --- I suggested fixing the emmintrin.h source for both eventually ... If you only fix AT11 then sometime later some will discover the difference and try fix it. And likely break it again. So fix AT immediately

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #7 from Steven Munroe --- Ok it could be that compiler behavior changed. You where testing gcc-trunk? Please try the same test with AT11 gcc7. I know I hit this!

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #11 from Steven Munroe --- The requirement was to reduce the use of (in-line) assembler in libraries. Asm is error prone in the light of 32/64-bit ABI difference and the compiler (usual) generates the correct code for the target.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #18 from Steven Munroe --- (In reply to jos...@codesourcery.com from comment #17) > And, when long is 64-bit, there is no corresponding standard function to > round to 32-bit integer with "invalid" raised for out-of-range results -

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #5 from Steven Munroe --- You need to look at the generated asm code. And see what the compiler is doing. Basically it should be generating a vspltisw vr,si for vec_splat_s32. But if the immediate signed int (si) is greater than

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #13 from Steven Munroe --- WTF which part of requirement did you not understand. You you should implement the direct moves (to GPRs) to complete the __builtin_fctid and __builtin_fctiw implementation. But to just remove them is

[Bug target/85830] vec_popcntd is improperly defined in altivec.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830 --- Comment #3 from Steven Munroe --- (In reply to Carl Love from comment #2) > Hit the save button a little too fast missed putting in everything I > intended to put in. Lets try to get it all in. > > > In altivec.h they are defined as: > >

[Bug c/96139] New: Vector element extract mistypes long long int down to long int

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- When printing vector element for example: printf ("%s %016llx,%016llx\n", prefix, val[1], val[0]); where val is a vector uns

[Bug c/96139] Vector element extract mistypes long long int down to long int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 --- Comment #1 from Steven Munroe --- Created attachment 48851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48851=edit Test case for printf of vector long long int elements

[Bug target/96139] Vector element extract mistypes long long int down to long int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 --- Comment #3 from Steven Munroe --- (In reply to Bill Schmidt from comment #2) > Have you tried it for -m32, out of curiosity? no

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #7 from Steven Munroe --- Then you have problem as @pcrel is never valid for an instruction like lxsd%X1. Seems like you will need a new constrain or modifier specific to @pcrel.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #5 from Steven Munroe --- I would think you need to look at the instruction and the "m" constraint. In this case lxsd%X1 would need to be converted to plxsd and the "m" constraint would have to allow @pcrel. I would think a static

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #13 from Steven Munroe --- "We want to use plain TImode instead of V1TImode on newer cpus." Actually I disagree. We have vector __int128 in the ABI and with POWER10 a complete set arithmetic operations for 128-bit in VRs. Also

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #5 from Steven Munroe --- Any progress on this?

[Bug middle-end/99293] Built-in vec_splat generates sub-optimal code for -mcpu=power10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293 --- Comment #1 from Steven Munroe --- Created attachment 50264 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50264=edit Compile test for simplied test case Download vec_dummy.c and vec_int128_ppc.h into a local directory and compile gcc

[Bug middle-end/99293] New: Built-in vec_splat generates sub-optimal code for -mcpu=power10

Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 50263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50263=edit Simplified test case While adding c

[Bug rtl-optimization/100085] New: Bad code for union transfer from __float128 to vector types

Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 50595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50595=edit Reduced example of un

[Bug rtl-optimization/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 Steven Munroe changed: What|Removed |Added CC||munroesj at gcc dot gnu.org

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #4 from Steven Munroe --- I am seeing this a similar problem with union transfers from __float128 to __int128. static inline unsigned __int128 vec_xfer_bin128_2_int128t (__binary128 f128) { __VF_128 vunion;

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 Steven Munroe changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #16 from Steven Munroe --- Created attachment 52510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52510=edit Reduced tests for xfers from _float128 to vector or __int128 Cover more types including __int128 and vector

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #21 from Steven Munroe --- Yes I was told by Peter Bergner that the fix from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085#c15 had been back ported top AT15.0-1. But when ran this test with AT15.0-1 I saw: :

[Bug target/100085] Bad code for union transfer from __float128 to vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #23 from Steven Munroe --- Ok, but I strongly recommend a compiler test that verify that the compiler is generating the expected code (for this and other cases). We have a history of common code changes (accidental or deliberate)

[Bug target/104124] Poor optimization for vector splat DW with small consts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104124 Steven Munroe changed: What|Removed |Added Attachment #52236|0 |1 is obsolete|

[Bug target/104124] Poor optimization for vector splat DW with small consts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104124 Steven Munroe changed: What|Removed |Added CC||munroesj at gcc dot gnu.org

[Bug target/104124] New: Poor optimization for vector splat DW with small consts

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- It looks to me like the compiler is seeing register pressure caused by loading all the vector long long constants I need in my code

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645 --- Comment #6 from Steven Munroe --- (In reply to Carl Love from comment #5) > There are a couple of issues with the test case in the attachment. For > example one of the tests is: > > > static inline vui64_t > vec_vsldbi_64 (vui64_t vra,

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645 --- Comment #3 from Steven Munroe --- (In reply to Peter Bergner from comment #1) > I see that we have created built-in overloads for signed and unsigned vector > char through vector long long. That said, the rs6000-builtins.def only > seems

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645 Steven Munroe changed: What|Removed |Added Attachment #56018|0 |1 is obsolete|

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645 --- Comment #4 from Steven Munroe --- Actually shift/rotate intrinsic: ,vec_rl, vec_rlmi, vec_rlnm, vec_sl, vec_sr, vec_sra Support vector __int128 as required for the PowerISA 3.1 POWER vector shift/rotate quadword instructions But:

[Bug target/111645] New: Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 56018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56018=edit example of the problem. Comp

[Bug c/106755] New: Incorrect code gen for altivec intrinsics with constant inputs

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 53514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53514=edit Reducted test case for vec_muludq() with m

[Bug c/110795] New: Bad code gen for vector compare booleans

Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 55626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55626=edit Test examples for vector code combinining vector compare combined with logi

[Bug target/110795] Bad code gen for vector compare booleans

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110795 --- Comment #2 from Steven Munroe --- Also fails with gcc11/12. Also fails with Advance Toolchain 10.0 GCC 6.4.1. It might fail for all version between GCC 6 and 13.

[Bug target/110795] Bad code gen for vector compare booleans

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110795 --- Comment #1 from Steven Munroe --- Created attachment 55627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55627=edit Main and unit-test. When compiled and linked with vec_divide.c will verify if the divide code is correct or not.

[Bug target/110795] Bad code gen for vector compare booleans

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110795 --- Comment #5 from Steven Munroe --- Thanks, sorry I missed the obvious.

[Bug target/104124] Poor optimization for vector splat DW with small consts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104124 --- Comment #5 from Steven Munroe --- Thanks