https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
--- Comment #15 from pc at gcc dot gnu.org ---
Author: pc
Date: Mon Apr 23 21:14:38 2018
New Revision: 259582
URL: https://gcc.gnu.org/viewcvs?rev=259582=gcc=rev
Log:
rs6000: Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
Carl Love changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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=gcc=rev
Log:
gcc/ChangeLog:
2018-04-20 Carl Love
PR target/83402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
--- Comment #12 from Segher Boessenkool ---
Author: segher
Date: Fri Apr 13 23:13:40 2018
New Revision: 259380
URL: https://gcc.gnu.org/viewcvs?rev=259380=gcc=rev
Log:
rs6000: Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
--- Comment #11 from Bill Schmidt ---
Conclusion is that we still need a fix to emmintrin.h along the lines of
Steve's original two comments. Additionally, we need to fix trunk to complain
about the out of range value, rather than quietly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
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!
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.
>
>
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
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,
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
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.
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);
15 matches
Mail list logo