and change llvm::sys::RunInterruptHandlers to call that function directly
instead of calling SignalHandler, because the rest of SignalHandler
invokes side effects which aren't appropriate, including raising the
signal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104896 91177308-0d34-0410-b5e6-96231b3b80d8
platforms to unbreak the darwin and linux builds. The BSD folks should feel
free to change the #if, if this breaks them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101703 91177308-0d34-0410-b5e6-96231b3b80d8
as it is more efficient than fork/exec.
Thanks to Eric for adding the autoconf check. It would be nice if
a cmake guru could add a cmake check for posix_spawn as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101693 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise, e.g. in the invocation like clang -DFOO=\"bar\" FOO macro
got the bar value, not "bar".
Patch by Alexander Esilevich!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99763 91177308-0d34-0410-b5e6-96231b3b80d8
libstdc++'s std::string class points to the interior of an allocation, valgrind
reports strings still alive at program termination as possible leaks. I didn't
use a ManagedStatic for this because System can't depend on Support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98716 91177308-0d34-0410-b5e6-96231b3b80d8
included when using global symbols to ask the linker for the addresses of
various functions. One of the symbols was actually getting declared by a
header included in DynamicLibrary.cpp, which conflicted with the "extern void*"
declaration in SearchForAddressOfSpecialSymbol().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98243 91177308-0d34-0410-b5e6-96231b3b80d8
TimeValue()::now().toEpochTime() is supposed to be the same as time(),
but it wasn't, because toEpoch subtracted PosixZeroTime, but now()
didn't add PosixZeroTime!
Add a unittest to check this works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94178 91177308-0d34-0410-b5e6-96231b3b80d8
DynamicLibrary::SearchForAddressOfSymbol and force them to have "C"
linkage.
Interestingly, GCC treats the block-scoped "extern" declarations we
previously had as if they were extern "C" declarations (or, at least,
were in the global namespace), so that GCC bug papered over this LLVM
bug. Clang and EDG get the linkage correct; this new variant seems to
work for both GCC and Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92020 91177308-0d34-0410-b5e6-96231b3b80d8
gcc warned that the function may not have a return value, indeed
for non-intel and non-amd X86 CPUs it is right (VIA, etc.).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91276 91177308-0d34-0410-b5e6-96231b3b80d8
x86 CPU detection for the X86 getHostCPUName too, and create a simple
getHostCPUName that returns "generic" for all else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91240 91177308-0d34-0410-b5e6-96231b3b80d8
MSVS2k8 doesn't define __i386__, hence all the CPU detection code was disabled.
Enable it by looking for _MSC_VER.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91217 91177308-0d34-0410-b5e6-96231b3b80d8
sys::cas_flag should be long on this platform, InterlockedAdd() is
defined only for the Itanium architecture (according to MSDN).
Patch by Michael Beck!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90748 91177308-0d34-0410-b5e6-96231b3b80d8
