I ran the test suite yesterday and when I came back this morning the
queue_user_work_item.cc test was hung. This could be why the
sanitizer-windows buildbot keeps randomly timing out. I updated all the
usages of WaitForSingleObject involving threading events. I'm assuming
the API can reliably wait for subprocesses, which is what the majority
of call sites use it for.
While I'm at it, we can simplify some EH tests now that clang can
compile C++ EH.
llvm-svn: 261338
We were erroneously reporting 16K as the page size on Windows because
the code that does the shadow mapping was using page size instead of
allocation granularity. After fixing that, we can resolve the FIXMEs in
the Windows implementations of GetPageSize and GetMmapGranularity by
calling GetSystemInfo instead of returning hard-coded, incorrect
answers.
llvm-svn: 261233
FreeBSD does not install a number of Clang-provided headers for the
compiler in the base system due to incompatibilities between FreeBSD's
and Clang's versions. As a workaround do not use --sysroot=. on FreeBSD
until this is addressed.
llvm.org/pr26651
Differential Revision: http://reviews.llvm.org/D17383
llvm-svn: 261229
There seems to be a difference between 2.12.1 and 2.12.2 in 64-bit build.
Tested on Scientific Linux 6.6, based on RHEL.
Differential Revision: http://reviews.llvm.org/D17190
llvm-svn: 261193
This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake.
This step will allow these macros to be re-used by the separated builtin build.
llvm-svn: 261108
Compiler-rt only relies on LLVM for lit support. Pushing this dependency down into the test and unitest layers will allow builtin libraries to be built without LLVM.
llvm-svn: 261105
__msan_unpoison uses intercepted memset which currently leads to a SEGV
when linking with libc++ under CentOS 7.
Differential Revision: http://reviews.llvm.org/D17263
llvm-svn: 261073
1. Add two explicit -stdlib=libstdc++ in conjunction with -static-libstdc++
2. Pass -nostdinc++ when adding include paths for libc++ built for tsan. This
prevents clang finding the headers twice which would confuse #include_next
Differential Revision: http://reviews.llvm.org/D17189
llvm-svn: 260883
FreeBSD also needs to have sanitizer_linux_libcdep.cc included,
otherwise linking will fail with "undefined reference to
`__sanitizer::GetRSS()'".
While here, tabify the FreeBSD part, similar to the other parts.
llvm-svn: 260839
r260695 caused extra push/pop instruction pair in __tsan_read1
implementation. Still, that change in InstCombine is believed to
be good, as it reduces the number of instructions performed.
Adjust the expectations to match the newly generated code.
llvm-svn: 260775
There's no obvious reason it should fail in this way but it's the only change
on the blamelist. I suspect stale lit*.cfg's from previous builds.
llvm-svn: 260672
The lit test-suite containing the unit tests needs to be explicitly specified
as an argument to lit.py since it is no longer discovered when the other tests
are run (because they are one directory deeper).
dfsan, lsan, and sanitizer_common don't show the same problem.
llvm-svn: 260669
Summary:
In some cases stack pointer register (SP) doesn't point into the thread
stack: e.g. if one is using swapcontext(). In this case LSan
conservatively tries to scan the whole thread stack for pointers.
However, thread stack (at least in glibc implementation) may also
include guard pages, causing LSan to crash when it's reading from them.
One of the solutions is to use a pthread_attr_getguardsize() to adjust
the calculated stack boundaries. However, here we're just using
IsAccessibleMemoryRange to skip guard pages and make the code (slightly)
less platform-specific.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17116
llvm-svn: 260554
This test isn't posix specific, but it doesn't pass on Windows and is
XFAILed. I suspect that this test, which is expected to fail, is causing
the hangs I'm seeing on our WinASan builder. Moving it to Posix seems
to be the cleanest way to avoid running it on Windows.
llvm-svn: 260480
It thinks that these functions don't match the function pointer type
that they are passed with:
GCDAProfiling.c(578) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(579) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(580) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
llvm-svn: 260475
that's not true in general. Instead, use a preference order to pick the
standard C++ signature 'char*(char*, int)' where possible and fall back to the
C signature 'char*(const char*, int)' only when it's unavailable.
llvm-svn: 260425
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when lsan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16859
llvm-svn: 260232
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16856
llvm-svn: 260231
Mike Aizatsky