| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 232269
|
| |
|
|
| |
llvm-svn: 231933
|
| |
|
|
| |
llvm-svn: 231930
|
| |
|
|
| |
llvm-svn: 231929
|
| |
|
|
|
|
|
|
|
|
| |
This will be followed by a change on the clang side to update
the only user of this function with the new version.
Differential Revision: http://reviews.llvm.org/D8074
Reviewed By: Reid Kleckner
llvm-svn: 231392
|
| |
|
|
|
|
|
|
| |
The first element of STACKFRAME64 is a struct and Clang wants us to put
braces around it's initialization. Instead, drop the zero. The result
should be the same.
llvm-svn: 231387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::sys::PrintBacktrace(FILE*) is supposed to print a backtrace
of the current thread given the current PC. This function was
unimplemented on Windows, and instead the only time we could
print a backtrace was as the result of an exception through
LLVMUnhandledExceptionFilter.
This patch implements backtracing of self by using
RtlCaptureContext to get a CONTEXT for the current thread, and
moving the printing and StackWalk64 code to a common method that
printing own stack trace and printing stack trace of an exception
can use.
Differential Revision: http://reviews.llvm.org/D8068
Reviewed by: Reid Kleckner
llvm-svn: 231382
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using SetConsoleTextAttribute() to set the foreground or
background color, if you don't explicitly set both colors, then
a default value of black will be chosen for whichever you don't
specify a value for.
This is annoying when you have a non default console background
color, for example, and you try to set the foreground color.
This patch gets the existing fg/bg color and when you set one
attribute, sets the opposite attribute to its existing color
prior to comitting the update.
Reviewed by: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D7967
llvm-svn: 230859
|
| |
|
|
| |
llvm-svn: 230685
|
| |
|
|
|
|
| |
macro. NFC; LLVM edition.
llvm-svn: 229335
|
| |
|
|
|
|
| |
r227519.
llvm-svn: 227574
|
| |
|
|
|
|
| |
does not fix all signal handlers, but does fix the most recent one.
llvm-svn: 227490
|
| |
|
|
| |
llvm-svn: 227470
|
| |
|
|
| |
llvm-svn: 227322
|
| |
|
|
|
|
| |
enabled.
llvm-svn: 227094
|
| |
|
|
| |
llvm-svn: 226669
|
| |
|
|
|
|
|
|
|
|
|
| |
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
|
| |
|
|
| |
llvm-svn: 224312
|
| |
|
|
| |
llvm-svn: 224311
|
| |
|
|
| |
llvm-svn: 224309
|
| |
|
|
|
|
|
| |
It makes more sense for ThreadLocal<const T>::get to return a const T*
and ThreadLocal<T>::get to return a T*.
llvm-svn: 224225
|
| |
|
|
|
|
|
| |
I didn't notice the problem first because on a non debug build the CRT was
just exiting the process without any message.
llvm-svn: 224139
|
| |
|
|
|
|
| |
I will add a real use in another commit.
llvm-svn: 224136
|
| |
|
|
|
|
| |
As a bonus we can actually check the return value.
llvm-svn: 224046
|
| |
|
|
| |
llvm-svn: 224029
|
| |
|
|
|
|
| |
This interface was added 2 years ago but users never developed.
llvm-svn: 223368
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In both the Unix and Windows variants, std::getenv was called and the
result passed directly to a function accepting a StringRef. This isn't
OK because it might return a null pointer and that causes the StringRef
constructor to assert (and generally produces crash-prone code if
asserts are disabled). Fix this by independently testing the result as
non-null prior to splitting things.
This in turn uncovered another bug in the Unix variant where it would
infinitely recurse if PATH="", or after this fix if PATH isn't set.
There is no need to recurse at all. Slightly re-arrange the code to make
it clear that we can just fixup the Paths argument based on the
environment if we find anything.
I don't know of a particularly useful way to test these routines in
LLVM. I'll commit a test to Clang that ensures that its driver correctly
handles various settings of PATH. However, I have no idea how to
correctly write a Windows test for the PATHEXT change. Any Windows
developers who could provide such a test, please have at. =D
Many thanks to Nick Lewycky and others for helping debug this. =/ It was
quite nasty for us to track down.
llvm-svn: 223099
|
| |
|
|
|
|
|
| |
Allows long paths for the executable and redirected stdin/stdout/stderr.
Addresses PR21563.
llvm-svn: 222671
|
| |
|
|
|
|
|
| |
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
if (ec = widenPath(path, path_utf16))
llvm-svn: 222122
|
| |
|
|
|
|
| |
on msc17. *These were added in VS 2013*
llvm-svn: 221971
|
| |
|
|
|
|
| |
VS 2012 doesn't have fminf or fmaxf.
llvm-svn: 221949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for LLI failure on Windows\X86: http://llvm.org/PR5053
LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh
The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).
For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.
Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols. However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.
Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations. The address of these
helper functions are used to patch up the CALL instruction at load time.
Reviewers: lhames, rnk
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D5387
Patch by Swaroop Sridhar!
llvm-svn: 221947
|
| |
|
|
|
|
| |
Fixes the MSVC "14" build.
llvm-svn: 221932
|
| |
|
|
|
|
|
|
|
|
| |
Windows normally limits the length of an absolute path name to 260
characters; directories can have lower limits. These limits increase
to about 32K if you use absolute paths with the special '\\?\'
prefix. Teach Support\Windows\Path.inc to use that prefix as needed.
TODO: Other parts of Support could also learn to use this prefix.
llvm-svn: 221841
|
| |
|
|
|
|
|
|
|
| |
Commit 220932 caused crash when building clang-tblgen on aarch64 debian target,
so it's blocking all daily tests.
The std::call_once implementation in pthread has bug for aarch64 debian.
llvm-svn: 221331
|
| |
|
|
| |
llvm-svn: 221258
|
| |
|
|
|
|
| |
signed/unsigned mismatch.
llvm-svn: 221252
|
| |
|
|
|
|
|
|
|
| |
SearchPath() to appease clang Driver's tests.
It seems SearchPath() doesn't show actual extension on the filesystem.
FIXME: Shall we use FindFirstFile() here?
llvm-svn: 221246
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1>C:\Program Files (x86)\Windows Kits\8.1\Include\um\minwinbase.h(46):
error C2146: syntax error : missing ';' before identifier 'nLength'
1>C:\Program Files (x86)\Windows Kits\8.1\Include\um\minwinbase.h(46):
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
...
including <windows.h> is actually required.
llvm-svn: 221244
|
| |
|
|
| |
llvm-svn: 221220
|
| |
|
|
| |
llvm-svn: 220936
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to initialize the ManagedStatic mutex.
Summary:
This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once.
These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once.
Reviewers: aaron.ballman, chapuni, chandlerc, rnk
Reviewed By: rnk
Subscribers: majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D5922
llvm-svn: 220932
|
| |
|
|
| |
llvm-svn: 220251
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most Unix-like operating systems guarantee that the file descriptor is
closed after a call to close(2), even if close comes back with EINTR.
For these systems, calling close _again_ will either do nothing or close
some other file descriptor open(2)'d by another thread. (Linux)
However, some operating systems do not have this behavior. They require
at least another call to close(2) before guaranteeing that the
descriptor is closed. (HP-UX)
And some operating systems have an unpredictable blend of the two
behaviors! (xnu)
Avoid this disaster by blocking all signals before we call close(2).
This ensures that a signal will not be delivered to the thread and
close(2) will not give us back EINTR. We restore the signal mask once
the operation is done.
N.B. This isn't a problem on Windows, it doesn't have a notion of EINTR
because signals always get delivered to dedicated signal handling
threads.
llvm-svn: 219189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible to start a program with one (or all) of the standard file
descriptors closed. Subsequent open system calls will give the program
a low-numbered file descriptor.
This is problematic because we may believe we are writing to standard
out instead of a file.
Introduce Process::FixupStandardFileDescriptors, a helper function to
remap standard file descriptors to /dev/null if they were closed before
the program started.
llvm-svn: 219170
|
| |
|
|
| |
llvm-svn: 218547
|
| |
|
|
| |
llvm-svn: 218374
|
| |
|
|
|
|
| |
'extern "C" static' is not accepted by g++-4.7. Rather to tweak, I just removed 'extern "C"', since it doesn't affect the ABI.
llvm-svn: 218290
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comparing ModuleName to the file names listed will
always fail.
I wonder how this code ever worked and what its
purpose was. Why exclude the msvc runtime DLLs
but not exclude all Windows system DLLs?
Anyhow, it does not function as intended.
clang-formatted as well.
llvm-svn: 218276
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main difference is the removal of
std::error_code exists(const Twine &path, bool &result);
It was an horribly redundant interface since a file not existing is also a valid
error_code. Now we have an access function that returns just an error_code. This
is the only function that has to be implemented for Unix and Windows. The
functions can_write, exists and can_execute an now just wrappers.
One still has to be very careful using these function to avoid introducing
race conditions (Time of check to time of use).
llvm-svn: 217625
|