[Bug target/95070] New: vec_cntlz_lsbb implementation uses BE semantics on LE

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- Created attachment 48512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48512&action=edit test case This: -- vector unsigned char a = { 0xFF, 0xF

[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082 Paul Clarke changed: What|Removed |Added CC||pc at us dot ibm.com --- Comment #2 from

[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 #2 from Paul Clarke --- I'd like to take a stab at fixing this.

[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 #3 from Paul Clarke --- (In reply to Steven Munroe from comment #0) > The rs6000/emmintrin.h implementation of _mm_slli_epi32 reports: > error: argument 1 must be a 5-bit signed literal > > For constant shift values > 15. I though

[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 #4 from Paul Clarke --- Created attachment 43829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43829&action=edit unhelpful testcase $ gcc --version gcc (GCC) 8.0.1 20180402 (experimental) Copyright (C) 2018 Free Software Found

[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 #6 from Paul Clarke --- (In reply to Steven Munroe from comment #5) > 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. > > Bu

[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 #8 from Paul Clarke --- (In reply to Steven Munroe from comment #7) > Please try the same test with AT11 gcc7. I know I hit this! voila! $ /opt/at11.0/bin/gcc -o 83402 83402.c -DNO_WARN_X86_INTRINSICS -Wall -mcpu=power8 -O3 In file

[Bug c++/77681] New: failing to inline simple function when using -fgnu-tm

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- Created attachment 39671 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39671&action=edit testcase where always_inline fails with -fgnu-tm I've used sever

[Bug c++/77681] failing to inline simple function when using -fgnu-tm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77681 --- Comment #1 from Paul Clarke --- shoot. this may be a dup of bug 53991

[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 Paul Clarke changed: What|Removed |Added CC||pc at us dot ibm.com --- Comment #10 from

[Bug c++/77681] failing to inline simple function when using -fgnu-tm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77681 Paul Clarke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #11 from Paul Clarke --- We use TM for a multi-producer-multi-consumer queue implementation, and ran into the issue reported in this bug. (I had opened bug 77681 before discovering this report.) This report is surprisingly old. Is

[Bug debug/98875] New: DWARF5 as default causes perf probe to hang

Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- I sent this to gcc-patches, but realized I should open a bug report: -- The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a failure in the test suite for the IBM

[Bug debug/98875] DWARF5 as default causes perf probe to hang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 --- Comment #3 from Paul Clarke --- The IBM Advance Toolchain supports SLES 15, where the latest version of libdw is 0.168. We'll work around the issue by reverting the commit for the version of GCC included with the Advance Toolchain. I didn't

[Bug target/102107] New: protocol register (r12) corrupted before a tail call

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- Created attachment 51367 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51367&action=edit preprocessed source (large) I've been working on an effor

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Paul Clarke changed: What|Removed |Added Attachment #51367|0 |1 is obsolete|

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #2 from Paul Clarke --- Created attachment 51369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51369&action=edit creduced version (tiny, but ugly)

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #3 from Paul Clarke --- Created attachment 51371 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51371&action=edit preprocessed source (a bit smaller) I was able to cut out a bit more than half of the original code. It gets mor

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #4 from Paul Clarke --- Created attachment 51372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51372&action=edit preprocessed source (yet a bit smaller) I was able to remove one of the cases of the switch statement in the fun

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #5 from Paul Clarke --- Fails with "-mcpu=power10" and "-O2" or "-O3".

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #8 from Paul Clarke --- $ /opt/at15.0/bin/gcc --version gcc (GCC) 11.2.1 20210802 (Advance-Toolchain 15.0-0) [ebcfb7a665c2]

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #11 from Paul Clarke --- This does produce the issue for me: -- $ git checkout remotes/vendors/ibm/gcc-11-branch gcc-AT $ mkdir gcc-AT-build $ cd gcc-AT-build $ ../gcc-AT/configure --enable-languages=c,c++ --disable-libada --disable-

[Bug target/102485] New: -Wa,-many no longer has any effect

Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- The assembler option "-many" tells the assembler to support assembly of instructions from any vintage of processor. This can be passed through the GCC compiler using the command l

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Paul Clarke changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/102485] -Wa,-many no longer has any effect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #2 from Paul Clarke --- GCC putting the base ".machine" directive at the beginning of the file makes any command-line use of "-many" (-Wa,-many) be ignored. Is that OK? "-many" is supposed to make those black boxes just work. This

[Bug target/102783] New: [powerpc] FPSCR manipulations cannot be relied upon

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- On all Power targets which support hardware floating-point, there are a few manipulations of the Floating-Point Status and Control Register (FPSCR) that have side-effects

[Bug target/101893] There is no vgbbd on p7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893 --- Comment #1 from Paul Clarke --- I'll take ownership of this, except I'm not sure how to effect that. The fix has been posted https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577023.html, and awaits reviews/approval.