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
Per feedback by Doug, we should avoid platform-specific implementations
in lib/Headers as much as possible.
This reverts commit r178110.
llvm-svn: 178181
Module "sse" implicitly exports module "sse2".
This is bad because we also have module "sse2" export module "sse" (as intended) so we end up with a cycle
in the module import graph:
1. sse2 -> (also imports) sse
2. sse -> (also imports) sse2
To eliminate the cycle remove 2.; importing module "sse2" will also import module "sse", but just importing
module "sse" will not also import module "sse2".
rdar://13240552
llvm-svn: 178117
- Add head 'prfchwintrin.h' to define '_m_prefetchw' which is mapped to
LLVM/clang prefetch builtin
- Add option '-mprfchw' to enable PRFCHW feature and pre-define '__PRFCHW__'
macro
llvm-svn: 178041
Clang's <stddef.h> provides definitions for the C standard library
types size_t, ptrdiff_t, and wchar_t. However, the system's C standard
library headers tend to provide the same typedefs, and the two
generally avoid each other using the macros
_SIZE_T/_PTRDIFF_T/_WCHAR_T. With modules, however, we need to see
*all* of the places where these types are defined, so provide the
typedefs (ignoring the macros) when modules are enabled.
llvm-svn: 177686
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
Several of the intrinsic headers were using plain non-reserved identifiers.
C++11 17.6.4.3.2 [global.names] p1 reservers names containing a double
begining with an underscore followed by an uppercase letter for any use.
I think I got them all, but open to being corrected. For the most part I
didn't bother updating function-like macro parameter names because I don't
believe they're subject to any such collission - though some function-like
macros already follow this convention (I didn't update them in part because
the churn was more significant as several function-like macros use the double
underscore prefixed version of the same name as a parameter in their
implementation)
llvm-svn: 172666
- New options '-mrtm'/'-mno-rtm' are added to enable/disable RTM feature
- Builtin macro '__RTM__' is defined if RTM feature is enabled
- RTM intrinsic header is added and introduces 3 new intrinsics, namely
'_xbegin', '_xend', and '_xabort'.
- 3 new builtins are added to keep compatible with gcc, namely
'__builtin_ia32_xbegin', '__builtin_ia32_xend', and '__builtin_ia32_xabort'.
- Test cases for pre-defined macro and new intrinsic codegen are added.
llvm-svn: 167665
While we're here, extend the module map to cover most of the
newly-added instrinsic headers. Only wmmintrin.h is missing, because
it needs to be split into AES/PCLMUL subheaders (as a separate commit).
llvm-svn: 167398
Corrected type for index of _mm256_mask_i32gather_pd
from 256-bit to 128-bit
Corrected types for src|dst|mask of _mm256_mask_i64gather_ps
from 256-bit to 128-bit
Support the following intrinsics:
_mm_mask_i32gather_epi64, _mm256_mask_i32gather_epi64,
_mm_mask_i64gather_epi64, _mm256_mask_i64gather_epi64,
_mm_mask_i32gather_epi32, _mm256_mask_i32gather_epi32,
_mm_mask_i64gather_epi32, _mm256_mask_i64gather_epi32
llvm-svn: 159403
Support the following intrinsics:
_mm_mask_i32gather_pd, _mm256_mask_i32gather_pd, _mm_mask_i64gather_pd
_mm256_mask_i64gather_pd, _mm_mask_i32gather_ps, _mm256_mask_i32gather_ps
_mm_mask_i64gather_ps, _mm256_mask_i64gather_ps
llvm-svn: 159222
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
goodness because it provides opportunites to cleanup things. For example,
uint64_t t1(__m128i vA)
{
uint64_t Alo;
_mm_storel_epi64((__m128i*)&Alo, vA);
return Alo;
}
was generating
movq %xmm0, -8(%rbp)
movq -8(%rbp), %rax
and now generates
movd %xmm0, %rax
rdar://11282581
llvm-svn: 155924
A test for this is checking if this compiles:
#include <float.h>
inline bool IsFinite(const double& number) {
return _finite(number) != 0;
}
That depends however on either mingw or msvc being installed, and
chapuni tells me there might be issues with float.h on mingw, so
no automated test is added.
llvm-svn: 155507
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
From the Intel Optimization Reference Manual, Section 11.6.2. When data cannot
be aligned or alignment is not known, 16-byte memory accesses may provide better
performance.
rdar://11076953
llvm-svn: 153091
match the behavior of GCC. Also add a test for these intrinsics, which
apparently have *zero* tests. =[ Not surprisingly, Clang crashed when
compiling these.
Fix the bug in CodeGen where we failed to bitcast the argument type to
x86mmx prior to calling the LLVM intrinsic. This fixes an assert on the
new 3dnow-builtins.c test.
This is one issue impacting the efforts to get Clang to emulate the
Microsoft intrinsics headers -- 3dnow intrinsics are implictitly made
available there.
llvm-svn: 150948
into using non-absolute system includes (<foo>)...
... and introduce another hack that is simultaneously more heineous
and more effective. We whitelist Clang-supplied headers that augment
or override system headers (such as float.h, stdarg.h, and
tgmath.h). For these headers, Clang does not provide a module
mapping. Instead, a system-supplied module map can refer to these
headers in a system module, and Clang will look both in its own
include directory and wherever the system-supplied module map
suggests, then adds either or both headers. The end result is that
Clang-supplied headers get merged into the system-supplied module for
the C standard library.
As a drive-by, fix up a few dependencies in the _Builtin_instrinsics
module.
llvm-svn: 149611
builds, and bring mm_alloc.h into the fold. Start playing some tricks
with these builtin modules to mirror the include_next tricks that the
headers already perform.
llvm-svn: 149434
each of the targets. Use this for module requirements, so that we can
pin the availability of certain modules to certain target features,
e.g., provide a module for xmmintrin.h only when SSE support is
available.
Use these feature names to provide a nearly-complete module map for
Clang's built-in headers. Only mm_alloc.h and unwind.h are missing,
and those two are fairly specialized at the moment. Finishes
<rdar://problem/10710060>.
llvm-svn: 149227
headers. The remaining headers require more sophisticated
requirements; they'll be handled separately. Part of
<rdar://problem/10710060>.
llvm-svn: 149206
Richard Smith