summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows
Commit message (Collapse)AuthorAgeFilesLines
...
* All signal handlers are required to have C language linkage in C++. This ↵Aaron Ballman2015-01-291-1/+1
| | | | | | does not fix all signal handlers, but does fix the most recent one. llvm-svn: 227490
* [Support][Windows] Unify dialog box suppression and print stack traces on abort.Michael J. Spencer2015-01-291-20/+28
| | | | llvm-svn: 227470
* [Hexagon] Replacing intrinsics for halfword adds and max/min word/dword.Colin LeMahieu2015-01-281-8/+0
| | | | llvm-svn: 227322
* [Support][Windows] Disable error dialog boxes when stack trace printing is ↵Michael J. Spencer2015-01-261-0/+8
| | | | | | enabled. llvm-svn: 227094
* Add missing include guards to WindowsSupport.h.Yaron Keren2015-01-211-0/+5
| | | | llvm-svn: 226669
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-1/+1
| | | | | | | | | | | 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
* Remove the last unnecessary member variable of mapped_file_region. NFC.Rafael Espindola2014-12-161-11/+6
| | | | llvm-svn: 224312
* Convert a member variable to a local variable. NFC.Rafael Espindola2014-12-161-3/+3
| | | | llvm-svn: 224311
* Remove unused member and simplify. NFC.Rafael Espindola2014-12-161-22/+3
| | | | llvm-svn: 224309
* ThreadLocal: Return a mutable pointer if templated with a non-const typeDavid Majnemer2014-12-151-1/+1
| | | | | | | 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
* Remove silly left over from the Windows resize_file implementation.Rafael Espindola2014-12-121-1/+0
| | | | | | | 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
* Pass a FD to resise_file and add a testcase.Rafael Espindola2014-12-121-12/+4
| | | | | | I will add a real use in another commit. llvm-svn: 224136
* Remove a convoluted way of calling close by moving the call to the only caller.Rafael Espindola2014-12-111-39/+7
| | | | | | As a bonus we can actually check the return value. llvm-svn: 224046
* Remove dead code. NFC.Rafael Espindola2014-12-111-48/+0
| | | | llvm-svn: 224029
* Remove dead code. NFC.Rafael Espindola2014-12-041-27/+4
| | | | | | This interface was added 2 years ago but users never developed. llvm-svn: 223368
* Fix several bugs in r221220's new program finding code.Chandler Carruth2014-12-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* More long path name support on Windows, this time in program execution.Paul Robinson2014-11-243-9/+24
| | | | | | | Allows long paths for the executable and redirected stdin/stdout/stderr. Addresses PR21563. llvm-svn: 222671
* silence gcc 4.9.1 warning in /llvm/lib/Support/Windows/Path.inc:564:39:Yaron Keren2014-11-171-1/+1
| | | | | | | warning: suggest parentheses around assignment used as truth value [-Wparentheses] if (ec = widenPath(path, path_utf16)) llvm-svn: 222122
* SearchForAddressOfSymbol(): Disable 3 symbols, copysignf, fminf, and fmaxf, ↵NAKAMURA Takumi2014-11-141-1/+1
| | | | | | on msc17. *These were added in VS 2013* llvm-svn: 221971
* Fix the VS 2012 buildReid Kleckner2014-11-131-5/+7
| | | | | | VS 2012 doesn't have fminf or fmaxf. llvm-svn: 221949
* Fix symbol resolution of floating point libc builtins in MCJITReid Kleckner2014-11-132-9/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid usage of char16_t as MSVC "14" doesn't appear to support itReid Kleckner2014-11-131-4/+4
| | | | | | Fixes the MSVC "14" build. llvm-svn: 221932
* Improve long path name support on Windows.Paul Robinson2014-11-131-38/+66
| | | | | | | | | | 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
* Revert 220932.Jiangning Liu2014-11-051-24/+0
| | | | | | | | | 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
* Remove FindProgramByName. NFC.Rafael Espindola2014-11-041-39/+0
| | | | llvm-svn: 221258
* Fix Visual C++ warning, Program.inc(85): warning C4018: '<' : ↵Yaron Keren2014-11-041-1/+1
| | | | | | signed/unsigned mismatch. llvm-svn: 221252
* sys::findProgramByName(): [Win32] Tweak to pass lowercase .exe to ↵NAKAMURA Takumi2014-11-041-0/+1
| | | | | | | | | 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
* #include <winbase.h> is not enough for Visual C++ 2013, it errors:Yaron Keren2014-11-041-1/+1
| | | | | | | | | | | | 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
* [Support][Program] Add findProgramByName(Name, OptionalPaths)Michael J. Spencer2014-11-041-0/+64
| | | | llvm-svn: 221220
* Speculative fix for Windows build after r220932Hans Wennborg2014-10-301-0/+5
| | | | llvm-svn: 220936
* Removing the static initializer in ManagedStatic.cpp by using llvm_call_once ↵Chris Bieneman2014-10-301-0/+19
| | | | | | | | | | | | | | | | | | | 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
* PR21202: Memory leak in Windows RWMutexImpl when using SRWLOCKDavid Blaikie2014-10-211-5/+3
| | | | llvm-svn: 220251
* Support: Don't call close again if we get EINTRDavid Majnemer2014-10-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support: Add a utility to remap std{in,out,err} to /dev/null if closedDavid Majnemer2014-10-061-0/+4
| | | | | | | | | | | | | | | 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
* clang-format of ChangeStdinToBinary & ChangeStdoutToBinary.Yaron Keren2014-09-261-4/+4
| | | | llvm-svn: 218547
* Windows/Host.inc: Reformat the header to fit 80-col.NAKAMURA Takumi2014-09-241-1/+1
| | | | llvm-svn: 218374
* Windows/DynamicLibrary.inc: Remove 'extern "C"' in ELM_Callback.NAKAMURA Takumi2014-09-231-1/+1
| | | | | | '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
* In this callback ModuleName includes the file path.Yaron Keren2014-09-221-26/+5
| | | | | | | | | | | | | | | 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
* Misc cleanups to the FileSytem api.Rafael Espindola2014-09-111-33/+13
| | | | | | | | | | | | | | | | 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
* Add writeFileWithSystemEncoding to LibLLVMSuppor.Rafael Espindola2014-09-033-4/+65
| | | | | | | | | | | | | | | | | | | | This patch adds to LLVMSupport the capability of writing files with international characters encoded in the current system encoding. This is relevant for Windows, where we can either use UTF16 or the current code page (the legacy Windows international characters). On UNIX, the file is always saved in UTF8. This will be used in a patch for clang to thoroughly support response files creation when calling other tools, addressing PR15171. On Windows, to correctly support internationalization, we need the ability to write response files both in UTF16 or the current code page, depending on the tool we will call. GCC for mingw, for instance, requires files to be encoded in the current code page. MSVC tools requires files to be encoded in UTF16. Patch by Rafael Auler! llvm-svn: 217068
* Merge TempDir and system_temp_directory.Rafael Espindola2014-08-261-17/+45
| | | | | | | | | We had two functions for finding the temp or cache directory. Each had a different set of smarts about OS specific APIs. With this patch system_temp_directory becomes the only way to do it. llvm-svn: 216460
* Refactor argument serialization logic when executing process. NFC.Rafael Espindola2014-08-251-13/+17
| | | | | | | | | | | | This patch refactors the argument serialization logic used in the Execute function, used to launch new Windows processes. There is a critical step that joins char** arguments into a single string, building the command line used to launch the new process, and the readability of this code is improved if this part is refactored in its own helper function. Patch by Rafael Auler! llvm-svn: 216411
* Remove dead code. Fixes pr20544.Rafael Espindola2014-08-081-5/+0
| | | | llvm-svn: 215243
* Windows: Don't wildcard expand /? or -?Hans Wennborg2014-07-241-0/+5
| | | | | | | Even if there's a file called c:\a, we want /? to be preserved as an option, not expanded to a filename. llvm-svn: 213894
* Perform wildcard expansion in Process::GetArgumentVector on Windows (PR17098)Hans Wennborg2014-07-161-19/+71
| | | | | | | | | | | | | | On Windows, wildcard expansion isn't performed by the shell, but left to the program itself. The common way to do this is to link with setargv.obj, which performs the expansion on argc/argv before main is entered. However, we don't use argv in Clang on Windows, but instead call GetCommandLineW so we can handle unicode arguments. This means we have to do wildcard expansion ourselves. A test case will be added on the Clang side. Differential Revision: http://reviews.llvm.org/D4529 llvm-svn: 213114
* Fix a -Wunused-local-typedefs warningAlp Toker2014-07-141-1/+1
| | | | llvm-svn: 213002
* Finishing touch for the std::error_code transition.Rafael Espindola2014-06-131-7/+7
| | | | | | | | | | | While std::error_code itself seems to work OK in all platforms, there are few annoying differences with regards to the std::errc enumeration. This patch adds a simple llvm enumeration, which will hopefully avoid build breakages in other platforms and surprises as we get more uses of std::error_code. llvm-svn: 210920
* Fix build on windows.Rafael Espindola2014-06-131-84/+89
| | | | llvm-svn: 210873
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-133-28/+25
| | | | llvm-svn: 210871
* Try to fix the windows build.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210837
OpenPOWER on IntegriCloud