maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/x86-builtin-palignr.c

9 lines
449 B
C
Raw Normal View History

Change -mno-mmx to be more compatible with gcc. Specifically, -mno-mmx should not imply -mno-sse. Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__. clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much. <rdar://problem/9694837> llvm-svn: 134770
2011-07-09 07:31:17 +08:00
// RUN: %clang_cc1 -ffreestanding -fsyntax-only -target-feature +ssse3 -target-feature +mmx -verify -triple x86_64-pc-linux-gnu %s
// RUN: %clang_cc1 -ffreestanding -fsyntax-only -target-feature +ssse3 -target-feature +mmx -verify -triple i686-apple-darwin10 %s
New test to verify that we see constant integers here. llvm-svn: 101611
2010-04-17 10:36:08 +08:00
#include <tmmintrin.h>
diagnose errors when a builtin that require constant arguments don't have them. For example, on: #include <emmintrin.h> int foo(int N) { __m128i white2; white2 = _mm_slli_si128(white2, N); return 0; } we used to get: fatal error: error in backend: Cannot yet select: intrinsic %llvm.x86.sse2.psll.dq now we get: /Users/sabre/t.c:4:11: error: argument to '__builtin_ia32_pslldqi128' must be a constant integer white2 = _mm_slli_si128(white2, N); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /Users/sabre/t.c:1: /Volumes/Projects/cvs/llvm/Debug+Asserts/lib/clang/2.9/include/emmintrin.h:781:13: note: instantiated from: ((__m128i)__builtin_ia32_pslldqi128((__m128i)(VEC), (IMM)*8)) ^ ~~~~~~~ 1 error generated. llvm-svn: 115374
2010-10-02 07:23:24 +08:00
__m64 test1(__m64 a, __m64 b, int c) {
[X86] Remove __extension__ from macro intrinsics when its not needed. I think this is a holdover from when we used to declare variables inside the macros. And then its been copy and pasted forward for years every time a new macro intrinsic gets added. Interestingly this caused some tests for IRGen to be slightly more optimized. We now return a zeroinitializer directly instead of going through a store+load. It also removed a bogus error message on another test. llvm-svn: 333613
2018-05-31 08:51:20 +08:00
return _mm_alignr_pi8(a, b, c); // expected-error {{argument to '__builtin_ia32_palignr' must be a constant integer}}
New test to verify that we see constant integers here. llvm-svn: 101611
2010-04-17 10:36:08 +08:00
}