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

2016-09-21 Thread pc at us dot ibm.com
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=edit testcase where always_inline fails with -fgnu-tm I've used several differ

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

2016-09-21 Thread pc at us dot ibm.com
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

2016-09-21 Thread pc at us dot ibm.com
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 c++/77681] failing to inline simple function when using -fgnu-tm

2016-09-21 Thread pc at us dot ibm.com
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

2016-09-21 Thread pc at us dot ibm.com
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 target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

2017-12-14 Thread pc at us dot ibm.com
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

2018-04-04 Thread pc at us dot ibm.com
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. > >

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

2018-04-04 Thread pc at us dot ibm.com
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 target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

2018-04-03 Thread pc at us dot ibm.com
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=edit unhelpful testcase $ gcc --version gcc (GCC) 8.0.1 20180402 (experimental) Copyright (C) 2018 Free Software Foundation,

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

2018-04-03 Thread pc at us dot ibm.com
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

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

2020-05-11 Thread pc at us dot ibm.com
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=edit test case This: -- vector unsigned char a = { 0xFF, 0xFF, 0x00, 0

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

2020-05-14 Thread pc at us dot ibm.com
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 debug/98875] New: DWARF5 as default causes perf probe to hang

2021-01-28 Thread pc at us dot ibm.com via Gcc-bugs
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

2021-02-18 Thread pc at us dot ibm.com via Gcc-bugs
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] protocol register (r12) corrupted before a tail call

2021-08-27 Thread pc at us dot ibm.com via Gcc-bugs
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=edit creduced version (tiny, but ugly)

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

2021-08-27 Thread pc at us dot ibm.com via Gcc-bugs
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=edit preprocessed source (large) I've been working on an effort to improve Pyt

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

2021-08-27 Thread pc at us dot ibm.com via Gcc-bugs
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

2021-08-31 Thread pc at us dot ibm.com via Gcc-bugs
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

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

2021-08-28 Thread pc at us dot ibm.com via Gcc-bugs
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=edit preprocessed source (a bit smaller) I was able to cut out a bit more than half of the original code. It gets more

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

2021-08-28 Thread pc at us dot ibm.com via Gcc-bugs
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=edit preprocessed source (yet a bit smaller) I was able to remove one of the cases of the switch statement in the function

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

2021-08-30 Thread pc at us dot ibm.com via Gcc-bugs
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/101893] There is no vgbbd on p7

2021-08-12 Thread pc at us dot ibm.com via Gcc-bugs
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.

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

2021-09-25 Thread pc at us dot ibm.com via Gcc-bugs
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/102783] New: [powerpc] FPSCR manipulations cannot be relied upon

2021-10-15 Thread pc at us dot ibm.com via Gcc-bugs
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/102485] -Wa,-many no longer has any effect

2021-10-04 Thread pc at us dot ibm.com via Gcc-bugs
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.

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

2021-09-27 Thread pc at us dot ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Paul Clarke changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

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

2021-08-30 Thread pc at us dot ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #5 from Paul Clarke --- Fails with "-mcpu=power10" and "-O2" or "-O3".