--- Comment #1 from Emmanuel dot Thome at inria dot fr 2008-05-29 13:20
---
Created an attachment (id=15700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15700action=view)
source file causing ICE on 4.3.0
tiramisu ~ $ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
--- Comment #3 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:02
---
Yes there is, the __builtin_ia32_psrlqi128 takes __m128 and not a vector
type.
ok. I guess you mean __m128i, for that particular case.
It very much seems that the texinfo documentation for this part of
--- Comment #4 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:09
---
This leaves the ICE problem in attachment 15700. Is my assembly constraint
bogus (in which case I'd prefer a nice diagnostic, as was the case in gcc
4.2.4, to an ICE) ? I tried three choices for the inline asm:
--- Comment #5 from ubizjak at gmail dot com 2008-05-29 14:30 ---
Please note that psrlq doesn't implement x[N] y[N] shift, but x[N] y
shift. That is, all elements are shifted by the same value. Please see Intel
instruction reference.
Also, psrlq doesn't support memory operands.
--
--- Comment #6 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:49
---
(In reply to comment #5)
Please note that psrlq doesn't implement x[N] y[N] shift, but x[N] y
shift. That is, all elements are shifted by the same value. Please see Intel
instruction reference.
yeah, I
--- Comment #7 from ubizjak at gmail dot com 2008-05-29 15:03 ---
(In reply to comment #6)
Also, psrlq doesn't support memory operands.
It does (for the shift count). Or my AMD doc is bogus.
Uh, indeed. I was looking into sse.md patterns. Unfortunatelly, it takes 128bit
operand
