summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm] [Support] Reimplement getMainExecutable() using sysctl on NetBSDMichal Gorny2019-03-031-2/+18
| | | | | | | | | | | | | | | | Use sysctl() to implement getMainExecutable() on NetBSD, rather than trying to guess the correct path from argv[0]. This is one of the fixes to recent clang-check-mac-libcxx-fixed-compilation-db.cpp test failure on NetBSD. This has been historically done on both FreeBSD and NetBSD in r303015, and reverted in r303285 due to buggy implementation on FreeBSD. However, FWIK the NetBSD implementation does not suffer from the same bugs and is more reliable than playing with argv[0]. Differential Revision: https://reviews.llvm.org/D56975 llvm-svn: 355283
* Fix non-Windows platforms build break introduced by r355065. Fixes:Alexandre Ganea2019-02-281-0/+1
| | | | | | | | | | In file included from /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm/lib/Support/Memory.cpp:14: /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm/include/llvm/Support/Memory.h:38:14: error: private field 'Flags' is not used [-Werror,-Wunused-private-field] unsigned Flags = 0; ^ 1 error generated. llvm-svn: 355066
* [Memory] Add basic support for large/huge memory pagesAlexandre Ganea2019-02-281-1/+2
| | | | | | | | | | | | | | | | | This patch introduces Memory::MF_HUGE_HINT which indicates that allocateMappedMemory() shall return a pointer to a large memory page. However the flag is a hint because we're not guaranteed in any way that we will get back a large memory page. There are several restrictions: - Large/huge memory pages aren't enabled by default on modern OSes (Windows 10 and Linux at least), and should be manually enabled/reserved. - Once enabled, it should be kept in mind that large pages are physical only, they can't be swapped. - Memory fragmentation can affect the availability of large pages, especially after running the OS for a long time and/or running along many other applications. Memory::allocateMappedMemory() will fallback to 4KB pages if it can't allocate 2MB large pages (if Memory::MF_HUGE_HINT is provided) Currently, Memory::MF_HUGE_HINT only works on Windows. The hint will be ignored on Linux, 4KB pages will always be returned. Differential Revision: https://reviews.llvm.org/D58718 llvm-svn: 355065
* Add OpenBSD support to be able to get the thread nameBrad Smith2019-02-071-0/+6
| | | | llvm-svn: 353367
* build: Remove the cmake check for malloc.h.Peter Collingbourne2019-02-061-4/+1
| | | | | | | | | | | As far as I can tell, malloc.h is only being used here to provide a definition of mallinfo (malloc itself is declared in stdlib.h via cstdlib). We already have a macro for whether mallinfo is available, so switch to using that instead. Differential Revision: https://reviews.llvm.org/D57807 llvm-svn: 353329
* MemoryBlock: Do not automatically extend a given size to a multiple of page ↵Rui Ueyama2019-01-231-6/+4
| | | | | | | | | | | | | | | | | | | | | | | size. Previously, MemoryBlock automatically extends a requested buffer size to a multiple of page size because (I believe) doing it was thought to be harmless and with that you could get more memory (on average 2KiB on 4KiB-page systems) "for free". That programming interface turned out to be error-prone. If you request N bytes, you usually expect that a resulting object returns N for `size()`. That's not the case for MemoryBlock. Looks like there is only one place where we take the advantage of allocating more memory than the requested size. So, with this patch, I simply removed the automatic size expansion feature from MemoryBlock and do it on the caller side when needed. MemoryBlock now always returns a buffer whose size is equal to the requested size. Differential Revision: https://reviews.llvm.org/D56941 llvm-svn: 351916
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1914-56/+42
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Support] Fix GNU/kFreeBSD buildEli Friedman2018-12-181-1/+1
| | | | | | | | Patch by James Clarke. Differential Revision: https://reviews.llvm.org/D55296 llvm-svn: 349434
* [Support/FileSystem] Add sub-second precision for atime/mtime of ↵Argyrios Kyrtzidis2018-11-261-5/+16
| | | | | | | | | | | | | | | | | | | | sys::fs::file_status on unix platforms Summary: getLastAccessedTime() and getLastModificationTime() provided times in nanoseconds but with only 1 second resolution, even when the underlying file system could provide more precise times than that. These changes add sub-second precision for unix platforms that support improved precision. Also add some comments to make sure people are aware that the resolution of times can vary across different file systems. Reviewers: labath, zturner, aaron.ballman, kristina Reviewed By: aaron.ballman, kristina Subscribers: lebedev.ri, mgorny, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D54826 llvm-svn: 347530
* [FileSystem] Add expand_tilde functionJonas Devlieghere2018-11-131-0/+12
| | | | | | | | | | | | In D54435 there was some discussion about the expand_tilde flag for real_path that I wanted to expose through the VFS. The consensus is that these two things should be separate functions. Since we already have the code for this I went ahead and added a function expand_tilde that does just that. Differential revision: https://reviews.llvm.org/D54448 llvm-svn: 346776
* Fix DragonFlyBSD buildDavid Carlier2018-11-101-1/+3
| | | | | | | | | | Reviewers: rnk, thakis Reviewed By: krytarowski Differential Revision: https://reviews.llvm.org/D54363 llvm-svn: 346577
* Commit missing comment edit and use correct cast to fix std::min overloadReid Kleckner2018-10-231-5/+5
| | | | llvm-svn: 345105
* [hurd] Make getMainExecutable get the real binary pathReid Kleckner2018-10-231-7/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On GNU/Hurd, llvm-config is returning bogus value, such as: $ llvm-config-6.0 --includedir /usr/include while it should be: $ llvm-config-6.0 --includedir /usr/lib/llvm-6.0/include This is because getMainExecutable does not get the actual installation path. On GNU/Hurd, /proc/self/exe is indeed a symlink to the path that was used to start the program, and not the eventual binary file. Llvm's getMainExecutable thus needs to run realpath over it to get the actual place where llvm was installed (/usr/lib/llvm-6.0/bin/llvm-config), and not /usr/bin/llvm-config-6.0. This will not change the result on Linux, where /proc/self/exe already points to the eventual file. Patch by Samuel Thibault! While making changes here, I reformatted this block a bit to reduce indentation and match 2 space indent style. Differential Revision: https://reviews.llvm.org/D53557 llvm-svn: 345104
* Add support for GNU Hurd in Path.inc and other placesSylvestre Ledru2018-10-231-3/+8
| | | | | | | | | | | | | | Summary: Patch by Svante Signell & myself Reviewers: rnk, JDevlieghere, efriedma Reviewed By: efriedma Subscribers: efriedma, JDevlieghere, krytarowski, llvm-commits, kristina Differential Revision: https://reviews.llvm.org/D53409 llvm-svn: 345007
* [Support] exit with custom return code for SIGPIPENick Desaulniers2018-10-121-0/+5
| | | | | | | | | | | | | | | | | | | | | Summary: We tell the user to file a bug report on LLVM right now, and SIGPIPE isn't LLVM's fault so our error message is wrong. Allows frontends to detect SIGPIPE from writing to closed readers. This can be seen commonly from piping into head, tee, or split. Fixes PR25349, rdar://problem/14285346, b/77310947 Reviewers: jfb Reviewed By: jfb Subscribers: majnemer, kristina, llvm-commits, thakis, srhines Differential Revision: https://reviews.llvm.org/D53000 llvm-svn: 344372
* Remove dead function user_cache_directory()Nico Weber2018-09-181-23/+0
| | | | | | | | | | | | It's been unused since it was added almost 3 years ago in https://reviews.llvm.org/D13801 Motivated by https://reviews.llvm.org/rL342002 since it removes one of the functions keeping a ref to SHGetKnownFolderPath. Differential Revision: https://reviews.llvm.org/D52184 llvm-svn: 342485
* [Support] sys::fs::directory_entry includes the file_type.Kristina Brooks2018-09-121-33/+46
| | | | | | | | | | | | | | | | This is available on most platforms (Linux/Mac/Win/BSD) with no extra syscalls. On other platforms (e.g. Solaris) we stat() if this information is requested. This will allow switching clang's VFS to efficiently expose (path, type) when traversing a directory. Currently it exposes an entire Status, but does so by calling fs::status() on all platforms. Almost all callers only need the path, and all callers only need (path, type). Patch by sammccall (Sam McCall) Differential Revision: https://reviews.llvm.org/D51918 llvm-svn: 342089
* Use a lambda for calls to ::open in RetryAfterSignalHans Wennborg2018-08-272-3/+8
| | | | | | | | | | In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing compile errors of RetryAfterSignal due to overload resolution. Wrapping the call in a lambda avoids this. Based on a patch by Chih-Wei Huang <cwhuang@linux.org.tw>! llvm-svn: 340751
* [Support] NFC: Allow modifying access/modification times independently in ↵Jordan Rupprecht2018-08-131-4/+9
| | | | | | | | | | | | | | | | | sys::fs::setLastModificationAndAccessTime. Summary: Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different. Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which. For existing callers, the 1-arg overload just sets both timestamps to the same thing. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50521 llvm-svn: 339628
* [Support] Build fix for Haiku when checking for a local filesystemTim Northover2018-07-181-0/+3
| | | | | | | | | Haiku does not expose information about local versus remote mounts, so just return false, like Cygwin. Patch by Niels Sascha Reedijk. llvm-svn: 337389
* Add OpenBSD support to the Threading codeBrad Smith2018-06-231-3/+5
| | | | llvm-svn: 335426
* Fix namespaces. No functionality change.Benjamin Kramer2018-06-161-0/+2
| | | | llvm-svn: 334890
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows we've observed that if you open a file, write to it, map it into memory and close the file handle, the contents of the memory mapping can sometimes be incorrect. That was what we did when adding an entry to the ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing intermittent build failures on Chromium's ThinLTO bots on Windows. More details are in the associated Chromium bug (crbug.com/786127). We can prevent this from happening by keeping a handle to the file open while the mapping is active. So this patch changes the mapped_file_region class to duplicate the file handle when mapping the file and close it upon unmapping it. One gotcha is that the file handle that we keep open must not have been created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system will prevent other processes from opening the file. We can achieve this by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead, we use SetFileInformationByHandle with FileDispositionInfo to manage the delete-on-close bit. This lets us remove the hack that we used to use to clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE. A downside of using SetFileInformationByHandle/FileDispositionInfo as opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using CreateFile to open the file while the flag is set, even within the same process. This doesn't seem to matter for almost every client of TempFile, except for LockFileManager, which calls sys::fs::create_link to create a hard link from the lock file, and in the process of doing so tries to open the file. To prevent this change from breaking LockFileManager I changed it to stop using TempFile by effectively reverting r318550. Differential Revision: https://reviews.llvm.org/D48051 llvm-svn: 334630
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-121-7/+28
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* Fix build errors on some configurationsPavel Labath2018-06-112-3/+3
| | | | | | | | | | | | It's been reported <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180611/559616.html> that template argument deduction for RetryAfterSignal fails if open is not prefixed with "::". This should help us build correctly on those platforms and explicitly specifying the namespace is more correct anyway. llvm-svn: 334403
* Attempt 3: Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-101-6/+4
| | | | | | | | | | | | | | | | | | I took some liberties and quoted fewer characters than before, based on an article from MSDN which says that only certain characters cause an arg to require quoting. This seems to be incorrect, though, and worse it seems to be a difference in Windows version. The bot that fails is Windows 7, and I can't reproduce the failure on Win 10. But it's definitely related to quoting and special characters, because both tests that fail have a * in the argument, which is one of the special characters that would cause an argument to be quoted before but not any longer after the new patch. Since I don't have Win 7, all I can do is just guess that I need to restore the old quoting rules. So this patch does that in hopes that it fixes the problem on Windows 7. llvm-svn: 334375
* Cleanup. NFCFangrui Song2018-06-102-2/+2
| | | | llvm-svn: 334357
* Revert "Resubmit "[Support] Expose flattenWindowsCommandLine.""Zachary Turner2018-06-101-4/+6
| | | | | | | | | This reverts commit 65243b6d19143cb7a03f68df0169dcb63e8b4632. Seems like it's not a flake. It might have something to do with the '*' character being in a command line. llvm-svn: 334356
* Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-101-6/+4
| | | | | | | | | There were a few linux compilation failures, but other than that I think this was just a flake that caused the tests to fail. I'm going to resubmit and see if the failures go away, if not I'll revert again. llvm-svn: 334355
* commandLineFitsWithinSystemLimits Overestimates System LimitsAlexander Kornienko2018-06-081-1/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: The function `llvm::sys::commandLineFitsWithinSystemLimits` appears to be overestimating the system limits. This issue was discovered while attempting to enable response files in the Swift compiler. When the compiler submits its frontend jobs, those jobs are subjected to the system limits on command line length. `commandLineFitsWithinSystemLimits` is used to determine if the job's arguments need to be wrapped in a response file. There are some cases where the argument size for the job passes `commandLineFitsWithinSystemLimits`, but actually exceeds the real system limit, and the job fails. `clang` also uses this function to decide whether or not to wrap it's job arguments in response files. See: https://github.com/llvm-mirror/clang/blob/master/lib/Driver/Driver.cpp#L1341. Clang will also fail for response files who's size falls within a certain range. I wrote a script that should find a failure point for `clang++`. All that is needed to run it is Python 2.7, and a simple "hello world" program for `test.cc`. It should run on Linux and on macOS. The script is available here: https://gist.github.com/dabelknap/71bd083cd06b91c5b3cef6a7f4d3d427. When it hits a failure point, you should see a `clang: error: unable to execute command: posix_spawn failed: Argument list too long`. The proposed solution is to mirror the behavior of `xargs` in `commandLinefitsWithinSystemLimits`. `xargs` defaults to 128k for the command line length size (See: https://fossies.org/dox/findutils-4.6.0/buildcmd_8c_source.html#l00551). It adjusts this depending on the value of `ARG_MAX`. Reviewers: alexfh Reviewed By: alexfh Subscribers: llvm-commits Tags: #clang Patch by Austin Belknap! Differential Revision: https://reviews.llvm.org/D47795 llvm-svn: 334295
* Clean up some code in Program.Zachary Turner2018-06-081-0/+2
| | | | | | | | | | NFC here, this just raises some platform specific ifdef hackery out of a class and creates proper platform-independent typedefs for the relevant things. This allows these typedefs to be reused in other places without having to reinvent this preprocessor logic. llvm-svn: 334294
* Add a file open flag that disables O_CLOEXEC.Zachary Turner2018-06-081-4/+7
| | | | | | | | | | | O_CLOEXEC is the right default, but occasionally you don't want this. This is especially true for tools like debuggers where you might need to spawn the child process with specific files already open, but it's occasionally useful in other scenarios as well, like when you want to do some IPC between parent and child. llvm-svn: 334293
* Expose a single global file open function.Zachary Turner2018-06-071-35/+14
| | | | | | | | | This one allows much more flexibility than the standard openFileForRead / openFileForWrite functions. Since there is now just one "real" function that does the work, all other implementations simply delegate to this one. llvm-svn: 334246
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-44/+81
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [Support] Use zx_cache_flush on Fuchsia to flush instruction cachePetr Hosek2018-06-061-1/+10
| | | | | | | | | Fuchsia doesn't use __clear_cache, instead it provide zx_cache_flush system call. Use it to flush instruction cache. Differential Revision: https://reviews.llvm.org/D47753 llvm-svn: 334068
* [Support] Add functions that operate on native file handles on Windows.Zachary Turner2018-06-041-0/+26
| | | | | | | | | | | | | | | | | | | | Windows' CRT has a limit of 512 open file descriptors, and fds which are generated by converting a HANDLE via _get_osfhandle count towards this limit as well. Regardless, often you find yourself marshalling back and forth between native HANDLE objects and fds anyway. If we know from the getgo that we're going to need to work directly with the handle, we can cut out the marshalling layer while also not contributing to filling up the CRT's very limited handle table. On Unix these functions just delegate directly to the existing set of functions since an fd *is* the native file type. It would be nice, very long term, if we could convert most uses of fds to file_t. Differential Revision: https://reviews.llvm.org/D47688 llvm-svn: 333945
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D47153 llvm-svn: 333307
* Revert 332750, llvm part (see comment on D46910).Nico Weber2018-05-201-1/+1
| | | | llvm-svn: 332823
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D46910 llvm-svn: 332750
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. Fix r332428 which I reverted in r332429. I originally used double-wide CAS because I was lazy, but some platforms use a runtime function for that which thankfully failed to link (it would have been bad for signal handlers otherwise). I use a separate flag to guard the data instead. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: steven_wu, llvm-commits llvm-svn: 332496
* [Unix] Indent ChangeStd{in,out}ToBinary.Fangrui Song2018-05-161-4/+4
| | | | llvm-svn: 332432
* Revert "Signal handling should be signal-safe"JF Bastien2018-05-161-161/+73
| | | | | | Some bots don't have double-pointer width compare-and-exchange. Revert for now.q llvm-svn: 332429
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46858 llvm-svn: 332428
* [NFC] pull a function into its own lambdaJF Bastien2018-05-151-19/+21
| | | | | | | | | As requested in D46858, pulling this function into its own lambda makes it easier to read that part of the code and reason as to what's going on because the scope it can be called from is extremely limited. We want to keep it as a function because it's called from the two subsequent lines. llvm-svn: 332325
* [NFC] Update commentsJF Bastien2018-05-151-20/+19
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* [Support] Support building LLVM for FuchsiaPetr Hosek2018-05-031-0/+3
| | | | | | | | | | These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-305-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* Remove a dead #ifdef.Nico Weber2018-04-301-2/+0
| | | | | | | Unix/Threading.inc should never be included on _WIN32. See also https://reviews.llvm.org/D30526#1082292 llvm-svn: 331151
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-1/+1
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
OpenPOWER on IntegriCloud