[Bug target/83933] [8 regression] gcc.target/powerpc/vsx-vector-6-le.c fails starting with r256798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83933 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Carl Love --- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c contains the expected instruction counts for the test when built for little endian. The actual code is in gcc/testsuite/gcc.target/powerpc/vsx-vector-6.h. The test function foo was missing the closing "}" resulting in the compile error. The issue was fixed with commit 256864 by Carl Love on 2018-01-18.
[Bug testsuite/84370] Invalid option used in test case gcc.target/powerpc/builtins-3-p9-runnable.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84370 --- Comment #2 from Carl Love --- I will put together a patch to fix this.
[Bug target/84384] new test case gcc.target/powerpc/builtins-4-int128-runnable.c fails on power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84384 Carl Love changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Carl Love --- Commited patch to update the dg directives. commit 257675 2/14/2018 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=257675
[Bug target/84384] new test case gcc.target/powerpc/builtins-4-int128-runnable.c fails on power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84384 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Carl Love --- Closing bug. Issue is fixed.
[Bug c/84422] New: ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 Bug ID: 84422 Summary: ICE on various builtin test functions when compiled with -mcpu=power7 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- On Power 8 LE the following builtin test function produce an internal compiler error when compiled with the command: gcc -c -m64 -mcpu=power7 gcc/testsuite/gcc.target/powerpc/builtins-3-runnable.c during RTL pass: vregs gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p8.c during RTL pass: vregs gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c during RTL pass: vregs gcc/testsuite/gcc.target/powerpc/sse2-pmuludq-1.c during RTL pass: expand For completeness, the following also fails and has an existing PR for it. gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c during RTL pass: reload Note, existing PR 83964,
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-16 Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Carl Love --- GCC trunk commit 257752 fixed the issue with: gcc/testsuite/gcc.target/powerpc/builtins-3-runnable.c during RTL pass: vregs
[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84371 --- Comment #5 from Carl Love --- Will, I am guessing the recent changes that I made to the vec_neg builtin might be getting you. The vec_neg was orignially using P7 expansion macros but it used P8 rtl so when compiled with -mcpu=power7 the vec_neg builtin would give an ICE. The macro expansions for vec_neg, vec_float2, vec_signed2 and vec_unsigned2 are all being changed from P7 expansion macros to P8 expansion macros to fix GCC internal compiler errors when compiled with -mcpu=power7. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 for the list of test cases that fail with -mcpu=power7.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #9 from Carl Love --- This test case is in the list in PR 84422 . Working on a patch.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #10 from Carl Love --- These builtins were per a request from Steve Monroe. Not sure why he wanted them or if he actually ever used them.
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 --- Comment #2 from Carl Love --- Moved Power 8 vec_float2, vec_signed2 and vec_unsigned2 builtin tests to new file builtins-3-runnable-p8.c. Fixed ICE for vec_signed2 and vec_unsigned2 which were found in builtins-3-runnable.c once the vec_float2 test was moved to a P8 test file. Commit 257937.
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 --- Comment #3 from Carl Love --- gcc/testsuite/gcc.target/powerpc/sse2-pmuludq-1.c Test requres Power 8 as a minimum. Compiling with -mcpu=power7 generates an ICE but the test requires Power8. So the ICE shouldn't be an issue under normal testing conditions.
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 --- Comment #4 from Carl Love --- gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p8.c during RTL pass: vregs gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c during RTL pass: vregs Both tests fixed with mainline commit 258006 on 2/26/2018
[Bug target/82907] [8 regression] gcc.target/powerpc/p9-xxbr-1.c fails after r254464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82907 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Carl Love --- The fix for the regression was committed on 22/14/2017. The commit number is 254732 by Carl Love
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #9 from Carl Love --- Commit 250295 reverts commit 249424 which was causing issues. commit 249424 is actually a fix for the vec_mule and vec_mulo support that was added in commit 248125. The original commit was using the wrong word size for the half word builtin, hence the need for commit 249424 to fix that.
[Bug target/79040] vec_cntlz redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79040 Carl Love changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #2 from Carl Love --- In revision 236676 of GCC in file gcc/config/rs6000/altivec.h #define vec_cntlz __builtin_vec_vclz at line 350. Revision 236677 dated 2016/05/24 by Meisner makes the following change to file gcc/config/rs6000/altivec.h Index: gcc/config/rs6000/altivec.h === --- gcc/config/rs6000/altivec.h (revision 236676) +++ gcc/config/rs6000/altivec.h (revision 236677) @@ -384,6 +384,23 @@ #define vec_vupklsw __builtin_vec_vupklsw #endif +#ifdef _ARCH_PWR9 +/* Vector additions added in ISA 3.0. */ +#define vec_vctz __builtin_vec_vctz +#define vec_cntlz __builtin_vec_vctz adds redefinition of vec_cntlz +#define vec_vctzb __builtin_vec_vctzb +#define vec_vctzd __builtin_vec_vctzd +#define vec_vctzh __builtin_vec_vctzh +#define vec_vctzw __builtin_vec_vctzw +#define vec_vprtyb __builtin_vec_vprtyb +#define vec_vprtybd __builtin_vec_vprtybd +#define vec_vprtybw __builtin_vec_vprtybw Michael Meissner, can you look at this issue please. Thanks.
[Bug target/79039] builtins-3-p9.c fails with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79039 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Carl Love --- The issue has been resolved by fixing the return and argument types. The fix was committed as follows: r244499 | carll | 2017-01-16 12:03:14 -0500 (Mon, 16 Jan 2017) | 7 lines gcc/testsuite/ChangeLog: 2017-01-16 Carl Love * gcc.target/powerpc/builtins-3-p9.c (test_ne_long()): Change arguments and return type to bool long long.
[Bug target/79545] New: gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545 Bug ID: 79545 Summary: gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- The following issue was found in gcc 6.1. It also exists in gcc5.4. The source and return operand types for xvcvuxdsp and xvcvsxdsp instructions do not match the instruction definitions from the Power ISA document. The current code expects a V2DF source and returns V4SI. The two instructions should take a V2DI source and return V4SF. Additionally, there is a typo in the instruction generation for the xvcvuxdsp instruction generates instruction xvcvuxwdp instead of xvcvuxdsp. The issues are in file gcc/config/rs6000/vsx.md for define_insn "vsx_xvcvsxdsp" and define_insn "vsx_xvcvuxdsp" RTL statements.
[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-15 Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Carl Love --- The issue has been fixed in mainline 7.0, commit r245460 on 2017-02-14. Commit r245460 needs to be back ported to GCC 5 and GCC 6.
[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545 --- Comment #2 from Carl Love --- Author: carll Date: Thu Feb 16 20:59:20 2017 New Revision: 245518 URL: https://gcc.gnu.org/viewcvs?rev=245518&root=gcc&view=rev Log: gcc/ChangeLog: 2017-02-16 Carl Love Backport from mainline commit r245460 on 2017-02-14 PR 79545 * config/rs6000/rs6000.c: Add case statement entry to make the xvcvuxdsp built-in argument unsigned. * config/rs6000/vsx.md: Fix the source and return operand types so they match the instruction definitions from the ISA document. Fix typo in the instruction generation for the (define_insn "vsx_xvcvuxdsp" statement. gcc/testsuite/ChangeLog: 2017-01-16 Carl Love Backport from mainline commit r245460 on 2017-02-14 PR 79545 * gcc.target/powerpc/vsx-builtin-3.c: Add missing test case for the xvcvsxdsp and xvcvuxdsp instructions. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/rs6000.c branches/gcc-5-branch/gcc/config/rs6000/vsx.md branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c
[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545 --- Comment #3 from Carl Love --- Author: carll Date: Fri Feb 17 21:04:49 2017 New Revision: 245552 URL: https://gcc.gnu.org/viewcvs?rev=245552&root=gcc&view=rev Log: gcc/ChangeLog: 2017-02-17 Carl Love Backport from mainline commit r245460 on 2017-02-14 PR 79545 * config/rs6000/rs6000.c: Add case statement entry to make the xvcvuxdsp built-in argument unsigned. * config/rs6000/vsx.md: Fix the source and return operand types so they match the instruction definitions from the ISA document. Fix typo in the instruction generation for the (define_insn "vsx_xvcvuxdsp" statement. gcc/testsuite/ChangeLog: 2017-01-17 Carl Love Backport from mainline commit r245460 on 2017-02-14 PR 79545 * gcc.target/powerpc/vsx-builtin-3.c: Add missing test case for the xvcvsxdsp and xvcvuxdsp instructions. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.c branches/gcc-6-branch/gcc/config/rs6000/vsx.md branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c
[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80982 --- Comment #2 from Carl Love --- Author: carll Date: Wed Jun 7 22:03:48 2017 New Revision: 248997 URL: https://gcc.gnu.org/viewcvs?rev=248997&root=gcc&view=rev Log: gcc/ChangeLog: 2017-06-07 Carl Love PR target/80982 * config/rs6000/altivec.md (double2): Fix the implementation of for BE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md
[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80982 Carl Love changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Carl Love --- Fix submitted upstream
[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80982 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-06-08 Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Carl Love --- Taking the bug, Fix has been submitted.
[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||carll at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Carl Love --- Issue is resolved. Closing bug.
[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Carl Love --- Closing issue
[Bug target/85830] vec_popcntd is improperly defined in altivec.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830 Carl Love changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Carl Love --- The fix has been applied to the current mainline and backported to GCC 10. Closing the bug as fixed.
[Bug target/85830] vec_popcntd is improperly defined in altivec.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #9 from Carl Love --- Issue fixed, closing.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Carl Love changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #8 from Carl Love --- Working on a patch to add the builtins listed in the ELFv2 ABI Appendix B.
[Bug target/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 --- Comment #2 from Carl Love --- The ABI has the builtin VEC_FIRST_MATCH_OR_EOS_ INDEX (ARG1, ARG2) which says Returns the element index of the position of either the first character match or an end-of-string (EOS) terminator. If no match or terminator, returns the number of characters as an element count in the vector argument. So, I do agree the builtin in question should be treating the EOS (null) as any other number for comparison purposes.
[Bug target/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-04-28 Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/87583] error: unrecognizable insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87583 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED CC||carll at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Carl Love --- The issue was fixed with a patch to mainline, backported to GCC 8 and 9
[Bug c/86414] New: AIX generates wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 Bug ID: 86414 Summary: AIX generates wrong Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- The generated code for test cases gcc/testsuite/gcc.target/powerpc/divkc3-2.c gcc/testsuite/gcc.target/powerpc/divkc3-3.c gcc/testsuite/gcc.target/powerpc/mulkc3-2.c gcc/testsuite/gcc.target/powerpc/mulkc3-3.c make a call to the DC mode routine not the expected KC mode routine when compiled on AIX. Specifically on gcc119, with GCC mainline revision 262441 gcc -S -O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi divkc3-2.c more divkc3-2.s .file "divkc3-2.c" .toc .csect .text[PR] .align 2 .align 4 .globl divide .globl .divide .csect divide[DS] divide: .long .divide, TOC[tc0], 0 .csect .text[PR] .divide: mflr 0 stw 31,-4(1) lfd 4,8(5) stw 0,8(1) lfd 3,0(5) mr 31,3 stwu 1,-80(1) lfd 2,8(4) lfd 1,0(4) bl .__divdc3 <<<<<<< Expected to see .__difkc3 The generated code for the other test files fail similarly on AIX.
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 --- Comment #1 from Carl Love --- Author: carll Date: Mon Jul 16 23:35:25 2018 New Revision: 262758 URL: https://gcc.gnu.org/viewcvs?rev=262758&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2018-07-16 Carl Love Forgot the PR number on the commit log. PR target/86414 2018-07-16 Carl Love PR target/86414 * gcc.target/powerpc/divkc3-2.c: Add dg-require-effective-target longdouble128. * gcc.target/powerpc/divkc3-3.c: Ditto. * gcc.target/powerpc/mulkc3-2.c: Ditto. * gcc.target/powerpc/mulkc3-3.c: Ditto. * gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts. * gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific. Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 --- Comment #2 from Carl Love --- Author: carll Date: Wed Jul 18 22:12:20 2018 New Revision: 262865 URL: https://gcc.gnu.org/viewcvs?rev=262865&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2018-07-18 Carl Love Backport from mainline 2018-07-16 Carl Love PR target/86414 * gcc.target/powerpc/divkc3-2.c: Add dg-require-effective-target longdouble128. * gcc.target/powerpc/divkc3-3.c: Ditto. * gcc.target/powerpc/mulkc3-2.c: Ditto. * gcc.target/powerpc/mulkc3-3.c: Ditto. * gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts. * gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/divkc3-2.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/divkc3-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr85456.c
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Carl Love --- Patches to fix test cases committed to mainline and GCC 8.
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Carl Love --- Issue resolved, closing.
[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 --- Comment #1 from Carl Love --- The builtins-1.c test fails on AIX. Again looks like the count should be 1 not 7 for AIX and linux. There is an additional failure on AIX for test file altivec-1-runnable.c. Looks like the compiler options for AIX are not correct to compile variables declared as type double.
[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 --- Comment #2 from Carl Love --- Author: carll Date: Mon Jul 23 16:16:41 2018 New Revision: 262934 URL: https://gcc.gnu.org/viewcvs?rev=262934&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2018-07-23 Carl Love PR 86591 * gcc.target/powerpc/altivec-1-runnable.c: Move vector double tests to file altivec-2-runnable.c. * gcc.target/powerpc/altivec-2-runnable.c: Add vector double tests. * gcc.target/powerpc/buitlins-1.c: Remove dg-final check for xxlor. Update dg-final test for __divdi3 and __udivdi3 instructions. Update comments for instruction generated by vec_mergeh, vec_perm, vec_round, vec_cts, vec_ctu, vec_cpsgn tests. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c trunk/gcc/testsuite/gcc.target/powerpc/builtins-1.c
[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Carl Love --- Committed fix
[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69431 --- Comment #2 from Carl Love --- Author: carll Date: Mon Oct 1 15:57:13 2018 New Revision: 264764 URL: https://gcc.gnu.org/viewcvs?rev=264764&root=gcc&view=rev Log: Update, forgot to put the PR number in the Change Log. gcc/ChangeLog: 2018-10-01 Carl Love PR 69431 * config/rs6000/rs6000-builtin.def (__builtin_mffsl): New. (__builtin_mtfsb0): New. (__builtin_mtfsb1): New. ( __builtin_set_fpscr_rn): New. (__builtin_set_fpscr_drn): New. * config/rs6000/rs6000.c (rs6000_expand_mtfsb_builtin): Add. (rs6000_expand_set_fpscr_rn_builtin): Add. (rs6000_expand_set_fpscr_drn_builtin): Add. (rs6000_expand_builtin): Add case statement entries for RS6000_BUILTIN_MTFSB0, RS6000_BUILTIN_MTFSB1, RS6000_BUILTIN_SET_FPSCR_RN, RS6000_BUILTIN_SET_FPSCR_DRN, RS6000_BUILTIN_MFFSL. (rs6000_init_builtins): Add ftype initialization and def_builtin calls for __builtin_mffsl, __builtin_mtfsb0, __builtin_mtfsb1, __builtin_set_fpscr_rn, __builtin_set_fpscr_drn. * config/rs6000.md (rs6000_mtfsb0, rs6000_mtfsb1, rs6000_mffscrn, rs6000_mffscdrn): Add define_insn. (rs6000_set_fpscr_rn, rs6000_set_fpscr_drn): Add define_expand. * doc/extend.texi: Add documentation for the builtins. gcc/testsuite/ChangeLog: 2018-10-01 Carl Love PR 69431 * gcc.target/powerpc/test_mffsl-p9.c: New file. * gcc.target/powerpc/test_fpscr_rn_builtin.c: New file. * gcc.target/powerpc/test_fpscr_drn_builtin.c: New file. * gcc.target/powerpc/test_fpscr_rn_builtin_error.c: New file. * gcc.target/powerpc/test_fpscr_drn_builtin_error.c: New file. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69431 Carl Love changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #3 from Carl Love --- Note, the actual commit was r264762. Commit r264764 added the PR number to the commit logs.
[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69431 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Carl Love --- Patch committed. Closing the bugzilla
[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69431 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Carl Love --- Closing
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 --- Comment #5 from Carl Love --- Author: carll Date: Wed Mar 14 23:01:12 2018 New Revision: 258539 URL: https://gcc.gnu.org/viewcvs?rev=258539&root=gcc&view=rev Log: gcc/ChangeLog: 2018-03-14 Carl Love PR target/84422 * config/rs6000/rs6000-builtin.def: Change expansion for VMULESW to BU_P8V_AV_2. Change expansion for VMULEUW to BU_P8V_AV_2. * config/rs6000/rs6000.c: Change ALTIVEC_BUILTIN_VMULESW to P8V_BUILTIN_VMULESW. Change ALTIVEC_BUILTIN_VMULEUW to P8V_BUILTIN_VMULEUW. Change ALTIVEC_BUILTIN_VMULOSW to P8V_BUILTIN_VMULOSW. Change ALTIVEC_BUILTIN_VMULOUW to P8V_BUILTIN_VMULOUW. * config/rs6000/rs6000-c.c: Change ALTIVEC_BUILTIN_VMULESW to P8V_BUILTIN_VMULESW. Change ALTIVEC_BUILTIN_VMULEUW to P8V_BUILTIN_VMULEUW. Change ALTIVEC_BUILTIN_VMULOSW to P8V_BUILTIN_VMULOSW. Change ALTIVEC_BUILTIN_VMULOUW to P8V_BUILTIN_VMULOUW. Modified: trunk/gcc/config/rs6000/rs6000-builtin.def trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/config/rs6000/rs6000.c
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 Carl Love changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Carl Love --- Commit 258942 removed the builtins for __builtin_fctid and __builtin_fctiw
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 Carl Love changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Carl Love --- gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c was fixed by reverting the patch that added them. Commit 258492 gcc/testsuite/gcc.target/powerpc/sse2-pmuludq-1.c was fixed by commit 258539 At this point all of the test cases that were generating and ICE for -mcpu=power7 have been fixed. Closing the issue.
[Bug target/85181] New: Loading wrong source/dest registers for xviexpdp instruction with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85181 Bug ID: 85181 Summary: Loading wrong source/dest registers for xviexpdp instruction with -O2 optimization Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- Created attachment 43830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43830&action=edit test case for xviexpdp instruction With -O2 optimization, we load the data into the wrong VR registers. With -O0 we load and use the same VSR registers. The results of the test case is wrong with -O2 optimization but the correct expected result was obtained with -O0. The compiler used is GCC 8 mainline Revision: 258857 The attached test code was extracted from the Valgrind test_isa_3_0.c. When the test code was compiled on 4/2/2018 on a Power 9 system with the mainline GCC 8.0, Revision: 258857 with optimization -O0 I got the code: gcc -g -O0 -o test_xviexpdp test_xviexpdp.c objdump -S -d test_xviexpdp > test_xviexpdp.dump I get the following generated code. 15d4: 50 81 22 39 addir9,r2,-32432 15d8: 98 4e 00 7c lxvd2x vs0,0,r9 15dc: 50 02 80 f1 xxswapd vs12,vs0 15e0: 00 00 00 60 nop 15e4: 60 81 22 39 addir9,r2,-32416 15e8: 98 4e 00 7c lxvd2x vs0,0,r9 15ec: 50 02 60 f1 xxswapd vs11,vs0 15f0: 00 00 00 60 nop 15f4: 80 81 22 39 addir9,r2,-32384 15f8: 98 4e 00 7c lxvd2x vs0,0,r9 15fc: 50 02 00 f0 xxswapd vs0,vs0 1600: c0 5f 0c f0 xviexpdp vs0,vs12,vs11 The results of running the code was correct. The data was loaded into vs12 and vs11 and these are the registers used in the xviexpdp instruction. I verified in gdb that vs12 and vs11 have the expected values and vs0 is correct after the instruction. With -O2 we have 14f8: ce e8 1f 7c lvx v0,r31,r29 14fc: ce f8 a0 7d lvx v13,0,r31 1500: ce f0 3f 7c lvx v1,r31,r30 1504: c0 0f 0d f0 xviexpdp vs0,vs13,vs1 Note, we are loading v13 and v1, then use vs13 and vs1. I verified that v13 and v1 have the correct values. So, we appear to be loading the wrong register set. Not sure why the optimized code loads the wrong registers. I don't see any issues with the inline assembly. Note, same compiler compiled the next day, on 4/3/2018, on the same machine with -O0 I get slightly different unoptimized code that doesn't work. What changed overnight I don't know but it is really annoying I can't exactly reproduce things. 15d0: 00 00 00 60 nop 15d4: 50 81 22 39 addir9,r2,-32432 15d8: 98 4e 00 7c lxvd2x vs0,0,r9 15dc: 51 02 20 f0 xxswapd vs33,vs0Now using vs33 not vs12 15e0: 00 00 00 60 nop 15e4: 60 81 22 39 addir9,r2,-32416 15e8: 98 4e 00 7c lxvd2x vs0,0,r9 15ec: 51 02 a0 f1 xxswapd vs45,vs0Now using vs45 not vs11 15f0: 00 00 00 60 nop 15f4: 80 81 22 39 addir9,r2,-32384 15f8: 98 4e 00 7c lxvd2x vs0,0,r9 15fc: 50 02 00 f0 xxswapd vs0,vs0 1600: 91 04 00 f0 xxlor vs32,vs0,vs0Now using vs32 not vs0 1604: c0 6f 01 f0 xviexpdp vs0,vs1,vs13 Note, we load VS register indexes that are 32 more then what is used in the xviexpdp instruction. I get all zeros for the result today, that is not the correct result. Don't know why things are compiling differently today, but the test case result is wrong. The test does generate the same wrong code when compiled with -O2 as it did yesterday. NOTE, this may not be the only instruction where this issue is occurring. Still investigating.
[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 #13 from Carl Love --- Author: carll Date: Fri Apr 20 15:18:24 2018 New Revision: 259524 URL: https://gcc.gnu.org/viewcvs?rev=259524&root=gcc&view=rev Log: gcc/ChangeLog: 2018-04-20 Carl Love PR target/83402 * config/rs6000/rs6000-c.c (rs6000_gimple_fold_builtin): Add size check for arg0. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[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 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED CC||carll at gcc dot gnu.org Resolution|--- |FIXED --- Comment #14 from Carl Love --- Marking this issue fixed, resolved, see comment 13.
[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177 Carl Love changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #4 from Carl Love --- The test is compiled with the options -maltivec -mpower9-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details --param vect-max-version-for-alias-checks=0 The test call abort and exits. The compile options can be reduced to -mpower9-vector -ftree-vectorize -O2 and still reproduce the error. Removing any of the three and the test will pass.
[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177 --- Comment #5 from Carl Love --- Created attachment 44166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44166&action=edit diff file The attachment is a side by side diff of good code and bad code. It shows the difference in the code generation that leads to the abort. It has been edited down to just where the code differs.
[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177 --- Comment #6 from Carl Love --- Printing the results rather then aborting, we see the value of ib[1] and ib[3] are swapped; ib[2] and ib[4] are swapped, then ib[5] and ib[7] are swapped and ib[6] and ib[8] are swapped. The pattern continues. ib[1] = 168, res[1] = 192 <-R1 ib[2] = 156, res[2] = 180 <-R2 ib[3] = 192, res[3] = 168 <-R1 ib[4] = 180, res[4] = 156 <-R2 ib[5] = 120, res[5] = 144 <-R3 ib[6] = 108, res[6] = 132 <-R4 ib[7] = 144, res[7] = 120 <-R3 ib[8] = 132, res[8] = 108 <-R4 ib[9] = 72, res[9] = 96<-R5 ib[10] = 60, res[10] = 84 <-R6 ib[11] = 96, res[11] = 72 <-R5 ib[12] = 84, res[12] = 60 <-R6 ib[13] = 24, res[13] = 48 <-R7 ib[14] = 12, res[14] = 36 <-R8 ib[15] = 48, res[15] = 24 <-R7 ib[16] = 36, res[16] = 12 <-R8
[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177 Carl Love changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org --- Comment #7 from Carl Love --- So the bug only occurs if GCC is configured wfor power8 or you also use the option -mcpu=power8 when compiling the test. If you configure with or use -mcpu-power9 then the proper code generation is done. Pat Haugen looked at this issue. It appears that GCC is calling the assembler with -mpower9 causing the P9 "stxvx" instruction to be generated to store the data in the correct order. In the case of power8 the compiler passes -mpower8 to the assembler which uses the "stxvx" extended mnemonic which maps to stxvd2x which doesn't store the data in the correct order.
[Bug target/102169] powerpc64 int memory operations using FP instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
Carl Love changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #5 from Carl Love ---
With no optimization, GCC generates a three instruction sequence to store to
the stack frame rather than using a single stw instruction.
Adding this for informational purposes per Segher's request.
The test program
#include
#include
int marker2 (int a) { return (1); }
int
main (int argc, char **argv, char **envp)
{
marker2 (43);
return argc;
}
Generates the three instruction sequence in both the main and marker2 function.
Just cutting and pasting the marker2 code for P9 and P10.
On Power 9
carll@marlin:~$ gcc -g stfiwx-bug.c -o stfiwx-bug
carll@marlin:~$ objdump -S -d stfiwx-bug > stfiwx-bug.dump
carll@marlin:~$ which gcc
/usr/bin/gcc
carll@marlin:~$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
int marker2 (int a) { return (1); }
7bc: f8 ff e1 fb std r31,-8(r1)
7c0: c1 ff 21 f8 stdur1,-64(r1)
7c4: 78 0b 3f 7c mr r31,r1
7c8: 78 1b 69 7c mr r9,r3
7cc: 2c 00 3f 91 stw r9,44(r31) << here
7d0: 01 00 20 39 li r9,1
7d4: 78 4b 23 7d mr r3,r9
7d8: 40 00 3f 38 addir1,r31,64
7dc: f8 ff e1 eb ld r31,-8(r1)
7e0: 20 00 80 4e blr
on Power 10
carll@ltcd97-lp1:~$ gcc -g stfiwx-bug.c -o stfiwx-bug
carll@ltcd97-lp1:~$ objdump -S -d stfiwx-bug > stfiwx-bug.dump
carll@ltcd97-lp1:~$ which gcc
/usr/bin/gcc
carll@ltcd97-lp1:~$ gcc --version
gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
int marker2 (int a) { return (1); }
7bc: f8 ff e1 fb std r31,-8(r1)
7c0: c1 ff 21 f8 stdur1,-64(r1)
7c4: 78 0b 3f 7c mr r31,r1
7c8: 78 1b 69 7c mr r9,r3
7cc: e6 01 09 7c mtfprwz f0,r9 << here
7d0: 2c 00 3f 39 addir9,r31,44 << here
7d4: ae 4f 00 7c stfiwx f0,0,r9 << here
7d8: 01 00 20 39 li r9,1
7dc: 78 4b 23 7d mr r3,r9
7e0: 40 00 3f 38 addir1,r31,64
7e4: f8 ff e1 eb ld r31,-8(r1)
7e8: 20 00 80 4e blr
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Carl Love --- Patch committed to fix issue
[Bug target/100930] PPC: Missing builtins for P9 vextsb2w, vextsb2w, vextsb2d, vextsh2d, vextsw2d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930 Carl Love changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #3 from Carl Love --- So, with a little archaeological digging.. Looks like the patch was committed to mainline on 6/8/2021 as follows: From db042e1603db5057314c404eded73c45f60ad2d6 Mon Sep 17 00:00:00 2001 From: Carl Love Date: Mon, 3 Feb 2020 14:41:42 -0600 Subject: [PATCH] RS6000 Add 128-bit Binary Integer sign extend operations This patch adds the 128-bit sign extension instruction support and corresponding builtin support. RS6000 Add 128-bit Binary Integer sign extend operations 2021-06-08 Carl Love gcc/ChangeLog * config/rs6000/altivec.h (vec_signextll, vec_signexti, vec_signextq): Add define for new builtins. * config/rs6000/altivec.md(altivec_vreveti2): Add define_expand. * config/rs6000/rs6000-builtin.def (VSIGNEXTI, VSIGNEXTLL): Add overloaded builtin definitions. (VSIGNEXTSB2W, VSIGNEXTSH2W, VSIGNEXTSB2D, VSIGNEXTSH2D,VSIGNEXTSW2D, VSIGNEXTSD2Q): Add builtin expansions. (SIGNEXT): Add P10 overload definition. * config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_VSIGNEXTI, P9V_BUILTIN_VEC_VSIGNEXTLL, P10_BUILTIN_VEC_SIGNEXT): Add overloaded argument definitions. * config/rs6000/vsx.md (vsx_sign_extend_v2di_v1ti): Add define_insn. (vsignextend_v2di_v1ti, vsignextend_qi_, vsignextend_hi_, vsignextend_si_v2di)[VIlong]: Add define_expand. Make define_insn vsx_sign_extend_si_v2di visible. * doc/extend.texi: Add documentation for the vec_signexti, vec_signextll builtins and vec_signextq. gcc/testsuite/ChangeLog * gcc.target/powerpc/int_128bit-runnable.c (extsd2q): Update expected count. Add tests for vec_signextq. * gcc.target/powerpc/p9-sign_extend-runnable.c: New test case. Looking at the GCC 11 tree it looks like I did backport and commit it there as well: commit 88b66b376844fe7c537ab229250a41a54e706eaf Author: Carl Love Date: Tue Jun 15 11:37:31 2021 -0500 RS6000 Add 128-bit Binary Integer sign extend operations This patch adds the 128-bit sign extension instruction support and corresponding builtin support. RS6000 Add 128-bit Binary Integer sign extend operations 2021-06-08 Carl Love gcc/ChangeLog * config/rs6000/altivec.h (vec_signextll, vec_signexti, vec_signext\ q): Add define for new builtins. * config/rs6000/altivec.md(altivec_vreveti2): Add define_expand. * config/rs6000/rs6000-builtin.def (VSIGNEXTI, VSIGNEXTLL): Add overloaded builtin definitions. (VSIGNEXTSB2W, VSIGNEXTSH2W, VSIGNEXTSB2D, VSIGNEXTSH2D,VSIGNEXTSW2\ D, VSIGNEXTSD2Q): Add builtin expansions. (SIGNEXT): Add P10 overload definition. * config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_VSIGNEXTI, P9V_BUILTIN_VEC_VSIGNEXTLL, P10_BUILTIN_VEC_SIGNEXT): Add overloaded argument definitions. * config/rs6000/vsx.md (vsx_sign_extend_v2di_v1ti): Add define_insn\ . (vsignextend_v2di_v1ti, vsignextend_qi_, vsignextend_hi_, vsignextend_si_v2di)[VIlong]: Add define_expand. Make define_insn vsx_sign_extend_si_v2di visible. * doc/extend.texi: Add documentation for the vec_signexti, vec_signextll builtins and vec_signextq. gcc/testsuite/ChangeLog * gcc.target/powerpc/int_128bit-runnable.c (extsd2q): Update expect\ ed count. Add tests for vec_signextq. * gcc.target/powerpc/p9-sign_extend-runnable.c: New test case. Probably should have fixed the commit log date. So, it looks to me like this has been done and the issue should be closed.
[Bug target/113950] New: PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
Bug ID: 113950
Summary: PowerPC, ICE with -O1 or higher compiling
__builtin_vsx_splat_2di test case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carll at gcc dot gnu.org
Target Milestone: ---
Power 10 LE
Fedora 38
Test of the __builtin_vsx_splat_2di ICEs on GCC 12 and later.
The following test case generates an ICE for -O1 and above. It does work for
-O0.
void abort (void);
int main ()
{
int i;
vector signed long long vsll_result, vsll_expected_result;
signed long long sll_arg1;
sll_arg1 = 300;
vsll_expected_result = (vector signed long long) {300, 300};
vsll_result = __builtin_vsx_splat_2di (sll_arg1); //ISSUE
for (i = 0; i < 2; i++)
if (vsll_result[i] != vsll_expected_result[i])
abort();
return 0;
}
The test case compiles fine with -O0.
Here is the output when I try to compile with -O1:
gcc -g -O1 compiler-bug.c -o compiler-bug
compiler-bug.c: In function ‘main’:
compiler-bug.c:19:1: error: unrecognizable insn:
19 | }
| ^
(insn 14 13 15 2 (set (reg:V2DI 117 [ _1 ])
(vec_duplicate:V2DI (const_int 300 [0x12c]))) "compiler-bug.c":12:17 -1
(nil))
during RTL pass: vregs
compiler-bug.c:19:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccnoI5lr.out file, please attach this to
your bugreport.
[Bug target/115466] New: rs6000 vec_ld built-in works on BE but not LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466 Bug ID: 115466 Summary: rs6000 vec_ld built-in works on BE but not LE Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- Created attachment 58416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58416&action=edit vec_ld test program The attached test program for the IBM rs6000 platform tests the vec_ld built-in for vector ints and vector floats. The output is correct on a BE system and incorrect on an LE system. gcc vec_ld_test.c -o vec_ld_test ./vec_ld_test BE output of test program: ./vec_ld_test ia[0-3] = 1, 2, 3, 4 via (should match ia[0-3]) = 1, 2, 3, 4 ia[4-7] = 5, 6, 7, 8 via (should match ia[4-7]) = 5, 6, 7, 8 fa = 10.00, 20.00, 30.00, 40.00 vfa (should match fa[0-3]) = 10.00, 20.00, 30.00, 40.00 vfa (should match fa[4-7]) = 50.00, 60.00, 70.00, 80.00 vec_ld (0, ia) = 1, 2, 3, 4 vec_ld (1, ia) = 1, 2, 3, 4 vec_ld (2, ia) = 1, 2, 3, 4 vec_ld (3, ia) = 1, 2, 3, 4 vec_ld (4, ia) = 1, 2, 3, 4 vec_ld (5, ia) = 1, 2, 3, 4 vec_ld (6, ia) = 1, 2, 3, 4 vec_ld (7, ia) = 1, 2, 3, 4 vec_ld (8, ia) = 1, 2, 3, 4 vec_ld (9, ia) = 1, 2, 3, 4 vec_ld (10, ia) = 1, 2, 3, 4 vec_ld (11, ia) = 1, 2, 3, 4 vec_ld (12, ia) = 1, 2, 3, 4 vec_ld (13, ia) = 1, 2, 3, 4 vec_ld (14, ia) = 1, 2, 3, 4 vec_ld (15, ia) = 1, 2, 3, 4 vec_ld (16, ia) = 5, 6, 7, 8 vec_ld (17, ia) = 5, 6, 7, 8 vec_ld (18, ia) = 5, 6, 7, 8 vec_ld (19, ia) = 5, 6, 7, 8 vec_ld (20, ia) = 5, 6, 7, 8 vec_ld (21, ia) = 5, 6, 7, 8 vec_ld (22, ia) = 5, 6, 7, 8 vec_ld (23, ia) = 5, 6, 7, 8 vec_ld (24, ia) = 5, 6, 7, 8 vec_ld (25, ia) = 5, 6, 7, 8 vec_ld (26, ia) = 5, 6, 7, 8 vec_ld (27, ia) = 5, 6, 7, 8 vec_ld (28, ia) = 5, 6, 7, 8 vec_ld (29, ia) = 5, 6, 7, 8 vec_ld (30, ia) = 5, 6, 7, 8 vec_ld (31, ia) = 5, 6, 7, 8 The same test program compliled and run on an LE machine: gcc vec_ld_test.c -o vec_ld_test ./vec_ld_test ia[0-3] = 1, 2, 3, 4 via (should match ia[0-3]) = -552597992, 32767, 1, 2 ia[4-7] = 5, 6, 7, 8 via (should match ia[4-7]) = 3, 4, 5, 6 fa = 10.00, 20.00, 30.00, 40.00 vfa (should match fa[0-3]) = 0.00, 0.00, 10.00, 20.00 vfa (should match fa[4-7]) = 30.00, 40.00, 50.00, 60.00 vec_ld (0, ia) = -552597992, 32767, 1, 2 vec_ld (1, ia) = -552597992, 32767, 1, 2 vec_ld (2, ia) = -552597992, 32767, 1, 2 vec_ld (3, ia) = -552597992, 32767, 1, 2 vec_ld (4, ia) = -552597992, 32767, 1, 2 vec_ld (5, ia) = -552597992, 32767, 1, 2 vec_ld (6, ia) = -552597992, 32767, 1, 2 vec_ld (7, ia) = -552597992, 32767, 1, 2 vec_ld (8, ia) = 3, 4, 5, 6 vec_ld (9, ia) = 3, 4, 5, 6 vec_ld (10, ia) = 3, 4, 5, 6 vec_ld (11, ia) = 3, 4, 5, 6 vec_ld (12, ia) = 3, 4, 5, 6 vec_ld (13, ia) = 3, 4, 5, 6 vec_ld (14, ia) = 3, 4, 5, 6 vec_ld (15, ia) = 3, 4, 5, 6 vec_ld (16, ia) = 3, 4, 5, 6 vec_ld (17, ia) = 3, 4, 5, 6 vec_ld (18, ia) = 3, 4, 5, 6 vec_ld (19, ia) = 3, 4, 5, 6 vec_ld (20, ia) = 3, 4, 5, 6 vec_ld (21, ia) = 3, 4, 5, 6 vec_ld (22, ia) = 3, 4, 5, 6 vec_ld (23, ia) = 3, 4, 5, 6 vec_ld (24, ia) = 7, 8, 1092616192, 1101004800 vec_ld (25, ia) = 7, 8, 1092616192, 1101004800 vec_ld (26, ia) = 7, 8, 1092616192, 1101004800 vec_ld (27, ia) = 7, 8, 1092616192, 1101004800 vec_ld (28, ia) = 7, 8, 1092616192, 1101004800 vec_ld (29, ia) = 7, 8, 1092616192, 1101004800 vec_ld (30, ia) = 7, 8, 1092616192, 1101004800 vec_ld (31, ia) = 7, 8, 1092616192, 1101004800 FYI, I also wrote a test to check the vec_st built-in. That seems to work fine on both LE and BE.
[Bug target/115466] rs6000 vec_ld built-in works on BE but not LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
--- Comment #4 from Carl Love ---
comment 1
Yes, I can confirm if I add the alignment statement to the declarations it
works fine.
I originally tried to use the built-in as part of a re-write of a function in
the Milvus AI source code. The function fvec_L2sqr_batch_4_ref() accounts for
about 90% of the workload run time. The code is:
fvec_L2sqr_batch_4_ref_v1(const float* x, const float* y0, const float* y1,
const float* y2, const float* y3, const size_t d, float& dis0, float& dis1,
float& dis2, float& dis3) {
float d0 = 0;
float d1 = 0;
float d2 = 0;
float d3 = 0;
for (size_t i = 0; i < d; ++i) {
const float q0 = x[i] - y0[i];
const float q1 = x[i] - y1[i];
const float q2 = x[i] - y2[i];
const float q3 = x[i] - y3[i];
d0 += q0 * q0;
d1 += q1 * q1;
d2 += q2 * q2;
d3 += q3 * q3;
}
dis0 = d0;
dis1 = d1;
dis2 = d2;
dis3 = d3;
}
When compiled with -O3, it does generate vsx instructions. But I noticed that
it was not using the vsx multiply add instructions. So, I tried rewriting it
to explicitly load a vector with the vec_ld built-in, followed by vec_sub and
vec_madd. Which by the way gives a 45% reduction in the execution time for my
standalone test.
At this point, not sure where the arguments get defined so adding the alignment
to the declaration is not so easy.
That said, Peter mentioned the vec_xl built-in which does seem to work. The
vec_xl does not require the data to be aligned from what I see in the PVIPR.
comment 3, Segher
I was looking at the PVIPR document when I chose the built-in for my rewrite.
Looking at the documentation, it does say "Load a 16-byte vector from the
memory address specified by the displacement and the pointer, ignoring the
low-order bits of the calculated address." In retrospect, I should have picked
up on the ignoring of the low-order bits to imply the addresses needed to be
aligned. It would really be good if the documentation explicitly said the data
must be 16-bye aligned. That said, my bad for not reading/understanding the
documentation well enough.
The vec_xl documentation does not say anything about ignoring the lower bits of
the address. So, in my case that is a better load built-in to use so I don't
have to try and find all the declarations for the arrays that could be passed
to the function.
It would be great to update the PVIPR to be more explicit about the alignment
needs.
Sorry everyone for the noise. I think we can close the issue as "User error".
[Bug target/115466] rs6000 vec_ld built-in works on BE but not LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466 --- Comment #6 from Carl Love --- comment 5, Segher Yes, I have some PVIPR changes that we have talked about previously. I will create a patch to also make the changes discussed here.
[Bug target/93448] PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||carll at gcc dot gnu.org --- Comment #7 from Carl Love --- Patch to add built-ins for DFP quantize have been committed.
[Bug target/93448] PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448 --- Comment #8 from Carl Love --- Status updated to resolved, fixed.
[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
Carl Love changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #9 from Carl Love ---
I made a copy of rs6000-overload.def and then with a series of emacs macros
converted the list of builtins to a script to grep for the builtins in the test
directory. Specifically from rs6000-overload.def:
[BCDADD, __builtin_bcdadd, __builtin_vec_bcdadd]
vsq __builtin_vec_bcdadd (vsq, vsq, const int);
BCDADD_V1TI
vuc __builtin_vec_bcdadd (vuc, vuc, const int);
BCDADD_V16QI
[BCDADD_EQ, __builtin_bcdadd_eq, __builtin_vec_bcdadd_eq]
signed int __builtin_vec_bcdadd_eq (vsq, vsq, const int);
BCDADD_EQ_V1TI
signed int __builtin_vec_bcdadd_eq (vuc, vuc, const int);
BCDADD_EQ_V16QI
Was converted to the bash script:
rm -f ../test1_not_found
NOT_FOUND='0 0 0'
check_name () {
str1=$(grep -r $1 * | wc)
# echo " output of command: $str1"
if [[ "$str1" == *"$NOT_FOUND"* ]]; then
echo "$1 not found" >> ../test1_not_found
fi
}
check_name "__builtin_bcdadd" "__builtin_vec_bcdadd"
check_name "__builtin_bcdadd_eq" "__builtin_vec_bcdadd_eq"
The script is passed the user built-in name ($str1) and the internal built-in
name ($str2). I ran the script in directory gcc/testsuite/gcc.target/powerpc
and it identified two tests ($str1) as not showing up in a test file. The
tests were: __builtin_bcdsub_ge and __builtin_bcdsub_le.
I figure if the first builtin name has a test associated with it that should be
sufficient. I will create a patch to add testcases for the two missing
builtin-names.
I did add to the script to see how many definitions have a test for the
built-in name $1 but not the built-in name $2 doesn't show up in a test file.
My script identified 86 of these cases. Not sure that we really need to add
test cases for the internal builtin name ($str). Thoughts?
[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
Carl Love changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #5 from Carl Love ---
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, vui64_t vrb, const unsigned int shb)
{
return vec_sldb (vra, vrb, shb);
}
When I tried to compile it, it seemed to compile. However if I take off the
static inline, then I get an error about in compatible arguments. The built-in
requires an explicit integer be based in the third argument. The following
worked for me:
static inline vui64_t
vec_vsldbi_64 (vui64_t vra, vui64_t vrb, const unsigned int shb)
{
return vec_sldb (vra, vrb, 1);
}
The compiler/assembler needs an explicit value for the third argument as it has
to generate the instruction with the immediate shift value as part of the
instruction. Hence a variable for the third argument will not work.
Agreed that the __int128 arguments can and should be supported. Patch to add
that support is in progress but will require getting the LLVM/OpenXL team to
agree to adding the __128int variants as well.
