OpenCL has large number of "builtin" functions ("builtin" in the sense of OpenCL spec) which are defined in header files. To compile OpenCL kernels using these builtin functions, a header file is needed.
This header file is based on the Khronos implementation (https://github.com/KhronosGroup/SPIR/blob/spirv-1.0/lib/Headers/opencl.h) with heavy refactoring.
Re-commit after fixing failures on ppc64/systemz etc.
Differential Revision: http://reviews.llvm.org/D18369
llvm-svn: 271197
OpenCL has large number of "builtin" functions ("builtin" in the sense of OpenCL spec) which are defined in header files. To compile OpenCL kernels using these builtin functions, a header file is needed.
This header file is based on the Khronos implementation (https://github.com/KhronosGroup/SPIR/blob/spirv-1.0/lib/Headers/opencl.h) with heavy refactoring.
Differential Revision: http://reviews.llvm.org/D18369
llvm-svn: 271136
For *_MANT_DIG, *_MAX_EXP and *_MIN_EXP, the C Standard does not list
the least requirements directly. This patch adjusts the test values with
refined ones.
Patch by Jorge Teixeira!
llvm-svn: 260710
Before, clang's internal assembler would reject the inline asm in clang's
Intrin.h. To make sure this doesn't happen for other Intrin.h functions using
__asm__ blocks, add 32-bit and 64-bit codegen tests for Intrin.h.
Sadly, these tests discovered that __readcr3 and __writecr3 have bad
implementations in 64-bit builds. This will have to be fixed in a follow-up.
llvm-svn: 248234
This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:
int __attribute__((__target__(("sse3")))) foo(int a) {
_mm_mwait(0, 0);
return 4;
}
This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.
llvm-svn: 239883
in POWER8.
These are the Clang-related changes for http://reviews.llvm.org/D9081
vadduqm
vaddeuqm
vaddcuq
vaddecuq
vsubuqm
vsubeuqm
vsubcuq
vsubecuq
All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and
powerpc64 macros.
http://reviews.llvm.org/D9903
llvm-svn: 238145
This patch adds support for the following new instructions in the
Power ISA 2.07:
vpksdss
vpksdus
vpkudus
vpkudum
vupkhsw
vupklsw
These instructions are available through the vec_packs, vec_packsu,
vec_unpackh, and vec_unpackl built-in interfaces. These are
lane-sensitive instructions, so the built-ins have different
implementations for big- and little-endian, and the instructions must
be marked as killing the vector swap optimization for now.
The first three instructions perform saturating pack operations. The
fourth performs a modulo pack operation, which means it can be
represented with a vector shuffle, and conversely the appropriate
vector shuffles may cause this instruction to be generated. The other
instructions are only generated via built-in support for now.
I noticed during patch preparation that the macro __VSX__ was not
previously predefined when the power8-vector or direct-move features
are requested. This is an error, and I've corrected that here as
well.
Appropriate tests have been added.
There is a companion patch to llvm for the rest of this support.
llvm-svn: 237500
xmmintrin.h includes emmintrin.h and vice versa if SSE2 is enabled. We break
this cycle for a modules build, and instead make the xmmintrin.h module
re-export the immintrin.h module. Also included is a fix for an assert in the
serialization code if a module exports another module that was declared later
in the same module map.
llvm-svn: 237321
Clang has introduced ::max_align_t in stddef.h in r201729, but libc++ was
already defining std::max_align_t on Darwin because there was none in the
global namespace. After that Clang commit though, libc++ started defining
std::max_align_t to be a typedef for ::max_align_t, which has a different
definition. This changed the ABI. This commit restores the previous
definition.
rdar://19919394 rdar://18557982
llvm-svn: 230292
This patch adds builtin support for xvdivdp and xvdivsp, along with a
new test case. The builtins are accessed using vec_div in altivec.h.
Builtins are listed (mostly) alphabetically there, so inserting these
changed the line numbers for deprecation warnings tested in
test/Headers/altivec-intrin.c.
There is a companion patch for LLVM.
llvm-svn: 221984
The use of the vec_lvsl and vec_lvsr interfaces are discouraged for
little endian targets since Power8 hardware is a minimum requirement,
and Power8 provides reasonable performance for unaligned vector loads
and stores. Up till now we have not provided "correct" (i.e., big-
endian-compatible) code generation for these interfaces, as to do so
produces poorly performing code. However, this has become the source
of too many questions.
With this patch, LLVM will now produce compatible code for these
interfaces, but will also produce a deprecation warning message for
PPC64LE when one of them is used. This should make the porting direction
clearer to programmers. A similar patch has recently been committed to
GCC.
This patch includes a test for the warning message. There is a companion
patch that adds two unit tests to projects/test-suite.
llvm-svn: 219137
When building with modules enabled, we were defining max_align_t as a typedef
for a different anonymous struct type each time it was included, resulting in
an error if <stddef.h> is not covered by a module map and is included more than
once in the same modules-enabled compilation of C11 or C++11 code.
llvm-svn: 218931
This commit makes two changes:
- Remove the push and pop instructions that were saving and restoring %ebx
before and after cpuid in 32-bit pic mode. We were doing this to ensure we
don't lose the GOT address in pic register %ebx, but this isn't necessary
because the GOT address is kept in a virtual register.
- In 64-bit mode, preserve base register %rbx around cpuid.
This fixes PR20311 and rdar://problem/17686779.
llvm-svn: 218173
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
llvm-svn: 213119
This adds the ARM ACLE hint intrinsic wrappers to arm_acle.h. These need to be
protected with a !defined(_MSC_VER) since MSVC (and thus clang in compatibility
mode) provide these wrappers as proper builtin intrinsics.
llvm-svn: 212891
This merges the two tests into one since there is no real reason to separate
them. It also fixes the test invocation to specify -fms-compatibility without
which we would end up without an Intrin.h header.
llvm-svn: 212563
Protect MMX specific declarations under a __MMX__ guard. This header can be
included on non-x86 architectures (e.g. ARM) which do not support the MMX ISA.
Use the preprocessor to prevent these declarations from being processed.
llvm-svn: 212512
Summary: This patch introduces ACLE header file, implementing extensions that can be directly mapped to existing Clang intrinsics. It implements for both AArch32 and AArch64.
Reviewers: t.p.northover, compnerd, rengolin
Reviewed By: compnerd, rengolin
Subscribers: rnk, echristo, compnerd, aemerson, mroth, cfe-commits
Differential Revision: http://reviews.llvm.org/D4296
llvm-svn: 211962
These are somewhat arbitrary tests that check if "thing goes fine" when
processing various platform-specific headers.
Also move warn-sysheader.cpp to Misc where the other diagnostics infrastructure
tests live.
File moves only.
llvm-svn: 207936
glibc expects that stddef.h only defines a single thing if either of these
defines is set. For example, before this change, a C file containing
#include <stdlib.h>
int ptrdiff_t = 0;
would compile with gcc but not with clang. Now it compiles with clang too.
This also fixes PR12997, where older versions of the Linux headers would define
NULL incorrectly, and glibc would define __need_NULL and expect stddef.h to
redefine NULL with the correct definition.
llvm-svn: 207606
See the bug and the cfe-commits thread "[patch] Let stddef.h redefine NULL if
__need_NULL is set" for discussion.
Fixes PR12997 and is similar to the __need_wint_t bits already in this file.
llvm-svn: 207482
This tests for broad compatibility with platform SDK headers using the clang
driver and so belongs alongside the other header ingtegration tests.
llvm-svn: 206687
They're already defined in ia32intrin.h, and this would cause including Intrin.h
in 64-bit mode to fail because of conflicting types. Update ms-intrin.cpp to
also run in 64-bit mode to catch things like this.
llvm-svn: 203714
This started failing for me the last time someone modified the AST file
format. It would be nice if we could just have lit take care of the
module cache used during testing for us, but this helps in the meantime.
llvm-svn: 203511
Summary:
Our usual definition of max_align_t wouldn't match up with MSVC if it
was used in a template argument.
Reviewers: chandlerc, rsmith, rnk
Reviewed By: chandlerc
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2924
llvm-svn: 202911
This breaks backwards compatibility with existing code. Previously, this
was defined as
#define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a), 0, (sel)))
Which basically accepts any pointer. Changing this to char* simply
breaks a lot of existing code. I have tried changing char* to
"const void*", which seems to be the right thing as per Intel
specification this should work on basically any pointer. However,
apparently this breaks windows compatibility (because of a conflicting
declaration in windows.h).
So, we probably need to #ifdef this based on whether clang is compiling
for windows. According to Chandler, this might be done by introducing an
additional symbol to a fake type in BuiltinsX86.def and then condition
the type expansion on the platform.
llvm-svn: 201775
This patch adds several built-ins that are required for ms
compatibility. _mm_prefetch must be a built-in because it takes a
compile-time constant argument and our prior approach of using a #define
to the current built-in doesn't work in the presence of re-declaration
of _mm_prefetch. The others can be obtained by including the windows
system headers. If a user includes the windows system headers but not
intrin.h they still need to work and therefore must be built-in because
we don't get a chance to implement them in intrin.h in this case.
llvm-svn: 201734
This definition is not chosen idly. There is an unfortunate reality with
max_align_t -- the specific nature of its definition leaks into the ABI
almost immediately. Because it is part of C11 and C++11 it becomes
essential for it to match with other systems on that ABI. There is an
effort to discourage any further use of this construct as a consequence
-- using max_align_t introduces an immediate ABI problem. We can never
update it to have larger alignment even as the microarchitecture changes
to necessitate higher alignment. =/
The particular definition here exactly matches the ABI of GCC's chosen
::max_align_t definition, for better or worse. This was written with the
help of Richard Smith who was decoding the exact ABI implications of the
selected definition in GCC. Notably, in-register arguments are impacted
by the particular definition chosen. =/
No one is under the illusion that this is a "good" or "useful"
definition of max_align_t, and we are working with the standards
committee to specify a more useful interface to address this need.
llvm-svn: 201729
PR18322. This test will be reenabled when the SDK gets fixed. In the meantime,
it is pretty disruptive to have this test keep failing.
llvm-svn: 200256
The part that checks that certain functions are marked deprecated doesn't
seem that useful, and it has the bad effect that the test hard-coded the
locations of the notes from that test.
llvm-svn: 199441
This ports the last Sema tests over to use the frontend directly, and adds a
local lit substitution to disable inappropriate %clang usage under this
directory.
llvm-svn: 199348
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.
This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings. By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent. It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.
This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated". It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
(e.g., "function" instead of "destructor"). By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away. This diagnostic can likely be further wordsmithed
to be shorter.
llvm-svn: 197627
Summary:
These are deprecated in VS 2012 according to MSDN. They don't actually
compile down to any code. They prevent the compiler from reordering
memory accesses across the barrier, which is what a memory-clobbering
volatile asm does.
Reviewers: echristo
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1954
llvm-svn: 192860
is no need to go through the driver indirection here, and it clutters
things up as dependencies can sneak in for specific things the driver is
doing.
llvm-svn: 191107
We already reject flags that don't have the CC1Option flag,
but we would previously do so after parsing the command-line
arguments.
Since the option parser now has a parameter for excluding options,
we should just use that instead.
Differential Revision: http://llvm-reviews.chandlerc.com/D1270
llvm-svn: 187668
This adds a test to make sure we define _WCHAR_T_DEFINED and
_NATIVE_WCHAR_T_DEFINED correctly in the preprocessor, and updates
stddef.h to set it when typedeffing wchar_t.
llvm-svn: 180918
- We shouldn't even try to include stdint.h in hosted mode, as the dependency
on even parsing a platforms stdint.h might fail for some targets.
llvm-svn: 179723
implementation of C99's attempt to control the C++ standard. *sigh*
The C99 standard says that certain macros in <stdint.h>, such as SIZE_MAX,
should not be defined when the header is included in C++ mode, unless
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined. The C++11 standard
says "Thanks, but no thanks" and C11 removed this rule, but various C library
implementations (such as glibc) follow C99 anyway.
g++ prior to 4.8 worked around the C99 / glibc behavior by defining
__STDC_*_MACROS in <cstdint>, which was incorrect, because <stdint.h> is
supposed to provide these macros too. g++ 4.8 works around it by defining
__STDC_*_MACROS in its builtin <stdint.h> header.
This change makes Clang act like g++ 4.8 in this regard: our <stdint.h> now
countermands any attempt by the C library to implement the undesired C99 rules,
by defining the __STDC_*_MACROS first. Unlike g++, we do this even in C++98
mode, since that was the intent of the C++ committee, matches the behavior
required in C11, and matches our built-in implementation of <stdint.h>.
llvm-svn: 179419
being included in C++. Don't define alignof or alignas in this case. Note that
the C++11 standard is broken in various ways here (it refers to the contents
of <stdalign.h> in C99, where that header did not exist, and doesn't mention
the alignas macro at all), but we do our best to do what it intended.
llvm-svn: 175708
Xcode-style clang builds only support Xcode's architectures, so mips
isn't available and the driver tries to use gcc instead. cc1 will go
ahead and do -fsyntax-only for any platform it knows about even if it
can't actually compile.
llvm-svn: 164742
This also adds a definition for uint64_t, which was causing build failures
on some platforms. (I'm actually surprised this didn't happen on more
builders, but maybe the search paths are different.)
llvm-svn: 164706
After discussion with several people, including Doug Gregor, we've
decided to change our approach here. If you have questions about this
header file, the commit removing it, etc., please reach out to me
off-list.
llvm-svn: 156322
header, along with a stub test to make sure it compiles in the
appropriate modes.
Thanks to Aaron Ballman for working with me to figure out the initial
strategy here, and to Nico for reviewing and pestering me to actually
commit it.
llvm-svn: 155425
Passing -verify to clang without -cc1 or -Xclang silently passes (with a
printed warning, but lit doesn't care about that). This change adds -cc1 or,
as is necessary in one case, -Xclang to fix this so that these tests are
actually verifying as intended.
I'd like to change the driver so this kind of mistake could not be made, but
I'm not entirely sure how. Further, since the driver only warns about unknown
flags in general, we could have similar bugs with a misspellings of arguments
that would be nice to find.
llvm-svn: 154776
This does not work so well with the -fno-lax-vector-conversions option for
testing the arm_neon.h header but that is a really useful test, so I split
this out to a separate Sema test to check for the warning.
llvm-svn: 120694
stdlib.h. There were numerous problems with forward declaring 'malloc' and
'free', but the most important is that these are reserved by POSIX and may be
implemented via a function-like macro.
As suggested by Dale Johannesen, I'm instead guarding the only include of this
in our builtin headers with __STDC_HOSTED__, and I've removed the include of
the header from the test suite. I'll discuss with folks whether we want to have
a hosted section of the test suite or not, and add it (and perhaps other tests)
back there if that's the direction.
llvm-svn: 119958
'long'. The practical upshot is so that the uint64_t we define in our stdint.h
ends up being compatible with that defined by gcc (at least on Darwin), which
otherwise could lead to type incompatibilities with other system headers.
llvm-svn: 107255
Hans Wennborg