https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #9 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #7)
> The other option is to change how intrinsics work on x86 and use resolve
> overloads inside the backend like how aarch64, arm and rs6000 backends all
> handle int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #8 from Jakub Jelinek ---
Looking at other intrinsics with {,unsigned }__int64{, const} * arguments, I
see
void _mm_maskstore_epi64 (__int64* mem_addr, __m128i mask, __m128i a)
void _mm256_maskstore_epi64 (__int64* mem_addr, __m256i m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #7 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #5)
> BTW, to avoid that warning, you could use in C:
> extern __inline __m128i
> __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> _mm_i32gather_ep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
Andrew Pinski changed:
What|Removed |Added
Keywords|wrong-code |diagnostic, rejects-valid
Ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #5 from Jakub Jelinek 2012-05-22
11:52:12 UTC ---
BTW, to avoid that warning, you could use in C:
extern __inline __m128i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm_i32gather_epi64 (
#ifdef __cplusplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #2 from Yukhin Kirill 2012-05-22
08:22:12 UTC ---
(In reply to comment #1)
> Please provide a testcase to show the problem.
I have no idea, which kind of test it should be.
These is just MS-ICC-GCC incompatibility issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
Yukhin Kirill changed:
What|Removed |Added
CC||areg.melikadamyan at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
