It seems MS headers have started using __readgsqword, and since it's
used in a header that doesn't include intrin.h, we can't implement it as
an inline function anymore.
That was already the case for __readfsdword, which Saleem added support
for in r220859. This patch reuses that codegen to implement all of
__read[fg]s{byte,word,dword,qword}.
Differential Revision: https://reviews.llvm.org/D31248
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298538 91177308-0d34-0410-b5e6-96231b3b80d8
__fastfail terminates the process immediately with a special system
call. It does not run any process shutdown code or exception recovery
logic.
Fixes PR31854
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294606 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These duplicate declarations cause a problem for CUDA compiles on
Windows. All implicitly-defined functions are host+device, and this
applies to the declarations in Builtin.def. But then when we see the
declarations in intrin.h, they have no attributes, so are host-only
functions. This is an error.
(A better fix might be to make these builtins host-only, but that is a
much bigger change.)
Reviewers: rnk
Subscribers: cfe-commits, echristo
Differential Revision: https://reviews.llvm.org/D28317
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291128 91177308-0d34-0410-b5e6-96231b3b80d8
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290539 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We need `__stosb` to be an intrinsic, because SecureZeroMemory function uses it without including intrin.h. Implementing it as a volatile memset is not consistent with MSDN specification, but it gives us target-independent IR while keeping the most important properties of `__stosb`.
Reviewers: rnk, hans, thakis, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25334
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284253 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Previously global 64-bit versions of _Interlocked functions broke buildbots on i386, so now I'm adding them as builtins for x86-64 and ARM only (should they be also on AArch64? I had problems with testing it for AArch64, so I left it)
Reviewers: hans, majnemer, mstorsjo, rnk
Subscribers: cfe-commits, aemerson
Differential Revision: https://reviews.llvm.org/D25576
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284172 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: _BitScan intrinsics (and some others, for example _Interlocked and _bittest) are supposed to work on both ARM and x86. This is an attempt to isolate them, avoiding repeating their code or writing separate function for each builtin.
Reviewers: hans, thakis, rnk, majnemer
Subscribers: RKSimon, cfe-commits, aemerson
Differential Revision: https://reviews.llvm.org/D25264
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284060 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We need x86-64-specific builtins if we want to implement some of the MS intrinsics - winnt.h contains definitions of some functions for i386, but not for x86-64 (for example _InterlockedOr64), which means that we cannot treat them as builtins for both i386 and x86-64, because then we have definitions of builtin functions in winnt.h on i386.
Reviewers: thakis, majnemer, hans, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24598
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283264 91177308-0d34-0410-b5e6-96231b3b80d8
On ARM, there are multiple versions of each of the intrinsics, with
acquire/relaxed/release barrier semantics.
The newly added ones are provided as inline functions here instead of builtins,
since they should only be available on certain archs (arm/aarch64).
This is necessary in order to compile C++ code for ARM in MSVC mode.
Patch by Martin Storsjö!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282447 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes compiling with headers from the Windows SDK for ARM, where the
YieldProcessor function (in winnt.h) refers to _ARM_BARRIER_ISHST.
The actual MSVC armintr.h contains a lot more definitions, but this is enough to
build code that uses the Windows SDK but doesn't use ARM intrinsics directly.
An alternative would to just keep the addition to intrin.h (to include
armintr.h), but not actually ship armintr.h, instead having clang's intrin.h
include armintr.h from MSVC's include directory. (That one works fine with
clang, at least for building code that uses the Windows SDK.)
Patch by Martin Storsjö!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277928 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156322 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155425 91177308-0d34-0410-b5e6-96231b3b80d8
Hans Wennborg