LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 9665 - __builtin_shufflevector requires a constant integer
Summary: __builtin_shufflevector requires a constant integer
Status: RESOLVED WONTFIX
Alias: None
Product: clang
Classification: Unclassified
Component: -New Bugs (show other bugs)
Version: 3.0
Hardware: PC Linux
: P enhancement
Assignee: Unassigned Clang Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-09 15:11 PDT by Giulio Eulisse
Modified: 2011-12-06 13:05 PST (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Giulio Eulisse 2011-04-09 15:11:09 PDT
The following bit of code:

  #include <xmmintrin.h>

  int main()
  {
    int n = 1;
    __m128 a, b;
    _mm_shuffle_ps(a, b, _MM_SHUFFLE(n, n, n, n));  
  }

compiles fine under gcc 4.5.1 but fails with clang 2.9 with:


  foo.cc:7:3: error: index for __builtin_shufflevector must be a constant integer
  _mm_shuffle_ps(a, b, _MM_SHUFFLE(n, n, n, n));  
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In file included from foo.cc:1:
  /build/ge/b/slc5_amd64_gcc451/external/llvm/2.9/bin/../lib/clang/2.9/include/xmmintrin.h:758:10:   note: instantiated from:
          (__builtin_shufflevector((__v4sf)(a), (__v4sf)(b),                \

Notice that if I use `const int n = 1` it is then accepted. What puzzles me is that if I do:
  
   #include <xmmintrin.h>
 
   int main()
   {
     int m = 1;                                                                                                                  
     const int n = m;
     __m128 a, b;
     _mm_shuffle_ps(a, b, _MM_SHUFFLE(n, n, n, n));
   }

it still gives the error reported above.
Comment 1 Eli Friedman 2011-04-09 17:10:15 PDT
The third argument for _mm_shuffle_ps is supposed to be a "integer constant expression" (using the term the the C standard uses). Anything beyond that is  an extension, and not portable.  I'd suggest using something like "enum { n = 1 };".
Comment 2 Luke Dalessandro 2011-12-06 11:00:14 PST
This bites me as well because Intel seems to use the (apparent) "unportable extension" in their avx intrinsic emulation header, downloadable as "avxintrin_emu.h" from "http://software.intel.com/en-us/articles/avx-emulation-header-file/". The header compiles without complaint on gcc on my Linux system up through 4.6.2.

Reproduce by downloading the header and including it in some temp.c file, and compiling with gcc -msse2 -c temp.c -o /dev/null. 

It's an inconvenient deviation from gcc's behavior (in the sense that there isn't any way that I can fix this header given my knowledge of SSE), so I updated to clang 3.0 and marked as an enhancement request.
Comment 3 Chris Lattner 2011-12-06 13:05:01 PST
We're not doing this.  Please ask Intel to fix their headers, or just use the Clang AVX headers.