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
Dmitri Gribenko