- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo,
I noticed a misbehavior when using _mm_set_epi16 with /arch:AVX(2). In debug mode I observe the following results of the following call:
mmTemp11 = _mm_set_epi16( 0, src11, 0, src10, 0, src11, 0, src10 );
-> mmTemp11.m128i_i16 0x00000074cf53bc80 {-2, -1, -2, 0, -2, 0, -2, 0}short[8] (for those unfamiliar with MSVC debugger, the problem is the bits 16:31 being set, when they clearly should be 0).
When src11=src10=-2. For positive values all works fine.
In release and profile configs I observe the program results being incorrect.
The problem does not occur with /arch:SSE42 or lower.
For now, I found the following workaround, but of course it would be nice if the program worked as intended:
mmTemp11 = _mm_cvtepu16_epi32( _mm_set_epi16( 0, 0, 0, 0, src11, src10, src11, src10 ) );
I don't think this behavior is intended. It works ok with gcc7/clang/msvc-19.16.
Compiler version is the one bundled with Intel Parallel Studio XE 2019.03.
Best regards,
Adam
- Tags:
- CC++
- Development Tools
- Intel® C++ Compiler
- Intel® Parallel Studio XE
- Intel® System Studio
- Optimization
- Parallel Computing
- Vectorization
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Found a minimal example to present the compiler bug. This only produces incorrect results when compiling with /Ob1, e.g.
icl /Ob1 /arch:CORE-AVX2 icc_bug.c
The following code demonstrates the problem:
#include <stdio.h> #include <emmintrin.h> void init_arr(short *arr) { arr[0] = -2; arr[1] = -2; } int main() { short arr[4]; init_arr( arr ); __m128i v = _mm_set_epi16( 0, arr[1], 0, arr[0], 0, arr[1], 0, arr[0] ); int b0_31 = _mm_cvtsi128_si32( v ); printf( "0x%x\n", ( b0_31 >> 16 ) & 0xffff ); }
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just wanted to clarify: the correct result should be zero and incorrect one should be 0xffff?
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, exactly. The expected results is 0x0, but with the specified compiler options the output 0xffff is being produced.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've reported this case to the Developer. Case number is CMPLRIL0-31587
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there anywhere I can follow the ticket?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is for internal tracking only.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page