summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-082-10/+12
| | | | | | | | | | 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-082-9/+22
| | | | | | | | | | | 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-072-86/+51
| | | | | | | | | 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
* [Support] Link libzircon.so when building LLVM for FuchsiaPetr Hosek2018-06-071-0/+3
| | | | | | | | This is necessary for zx_* symbols. Differential Revision: https://reviews.llvm.org/D47848 llvm-svn: 334232
* Fix unused private variable.Zachary Turner2018-06-071-1/+2
| | | | | | This parameter got lost in the refactor. Add it back. llvm-svn: 334223
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-078-144/+251
| | | | | | | | | | | | | | | | | 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
* [FileSystem] Remove OpenFlags param from several functions.Zachary Turner2018-06-051-14/+16
| | | | | | | | | | | | There was only one place in the entire codebase where a non default value was being passed, and that place was already hidden in an implementation file. So we can delete the extra parameter and all existing clients continue to work as they always have, while making the interface a bit simpler. Differential Revision: https://reviews.llvm.org/D47789 llvm-svn: 334046
* [Support] Add functions that operate on native file handles on Windows.Zachary Turner2018-06-042-30/+75
| | | | | | | | | | | | | | | | | | | | 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] Remove unused raw_ostream::handle whose anchor role was superseded ↵Fangrui Song2018-06-022-4/+1
| | | | | | by anchor() llvm-svn: 333817
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-016-14/+5
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* [ADT] Make escaping fn conform to coding guidelinesJonas Devlieghere2018-05-311-2/+2
| | | | | | | | As noted by Adrian on llvm-commits, PrintHTMLEscaped and PrintEscaped in StringExtras did not conform to the LLVM coding guidelines. This commit rectifies that. llvm-svn: 333669
* [dsymutil] Escape HTML special characters in plist.Jonas Devlieghere2018-05-301-0/+17
| | | | | | | | | | When printing string in the Plist, we weren't escaping the characters which lead to invalid XML. This patch adds the escape logic to StringExtras. rdar://39785334 llvm-svn: 333565
* Revert commit 333506Serge Pavlov2018-05-305-12/+36
| | | | | | | It looks like this commit is responsible for the fail: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/24382. llvm-svn: 333518
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-305-36/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a recommit of r333390, which was reverted in r333395, because it caused cyclic dependency when building shared library `LLVMDemangle.so`. In this commit `ItaniumDemangler.cpp` was not changed. The original commit message is below. In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 333506
* Reverted commits 333390, 333391 and 333394Serge Pavlov2018-05-295-12/+36
| | | | | | Build of shared library LLVMDemangle.so fails due to dependency problem. llvm-svn: 333395
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-295-36/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 333390
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-252-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* [x86] invpcid LLVM intrinsicGabor Buella2018-05-251-0/+1
| | | | | | | | | | | | | | | Re-add the feature flag for invpcid, which was removed in r294561. Add an intrinsic, which always uses a 32 bit integer as first argument, while the instruction actually uses a 64 bit register in 64 bit mode for the INVPCID_TYPE argument. Reviewers: craig.topper Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47141 llvm-svn: 333255
* [Support] Move header to WithColor headerJonas Devlieghere2018-05-241-1/+0
| | | | | | | Forgot to move the CommandLine.h include form the implementation to the header and didn't notice the failure with my local modules build. llvm-svn: 333177
* [Support] Add color cl category.Jonas Devlieghere2018-05-241-2/+4
| | | | | | | | | This commit adds a color category so tools can document this option and enables it for dwarfdump and dsymuttil. rdar://problem/40498996 llvm-svn: 333176
* Revert 332750, llvm part (see comment on D46910).Nico Weber2018-05-202-2/+2
| | | | llvm-svn: 332823
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-182-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* [X86][CET] Changing -fcf-protection behavior to comply with gcc (LLVM part)Alexander Ivchenko2018-05-181-2/+0
| | | | | | | | | | | | | | | | | | | | This patch aims to match the changes introduced in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The IBT feature definition is removed, with the IBT instructions being freely available on all X86 targets. The shadow stack instructions are also being made freely available, and the use of all these CET instructions is controlled by the module flags derived from the -fcf-protection clang option. The hasSHSTK option remains since clang uses it to determine availability of shadow stack instruction intrinsics, but it is no longer directly used. Comes with a clang patch (D46881). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46882 llvm-svn: 332705
* Support: Add a raw_ostream::write_zeros() function. NFCI.Peter Collingbourne2018-05-171-14/+26
| | | | | | | | | | This will eventually replace MCObjectWriter::WriteZeros. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47033 llvm-svn: 332675
* Revert 332508 as it caused problems in the clang test suite.Greg Clayton2018-05-161-4/+0
| | | | llvm-svn: 332555
* Fix llvm::sys::path::remove_dots() to return "." instead of an empty path.Greg Clayton2018-05-161-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D46887 llvm-svn: 332508
* [Timers] TimerGroup: add constructor from StringMap<TimeRecord>Roman Lebedev2018-05-161-0/+9
| | | | | | | | | | | | | | | | Summary: This is needed for the continuation of D46504, to be able to store the timings. Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: alexfh Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46939 llvm-svn: 332506
* [Timers] TimerGroup: make printJSONValues() method publicRoman Lebedev2018-05-161-0/+2
| | | | | | | | | | | | | | | | Summary: This is needed for the continuation of D46504, to be able to store the timings. Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: alexfh Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46938 llvm-svn: 332505
* [Timers] TimerGroup::printJSONValue(): print doubles with no precision lossRoman Lebedev2018-05-161-3/+7
| | | | | | | | | | | | | | | | Summary: Although this is not stricly required, i would very much prefer not to have known random precision losses along the way. Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: george.karpenkov Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46937 llvm-svn: 332504
* [Timers] TimerGroup::printJSONValues(): print mem timer with .mem suffixRoman Lebedev2018-05-161-1/+1
| | | | | | | | | | | | | | Summary: We have just used `.sys` suffix for the previous timer, this is clearly a typo Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: alexfh Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46936 llvm-svn: 332503
* Signal handling should be signal-safeJF Bastien2018-05-163-84/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-163-199/+87
| | | | | | 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-163-87/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-152-31/+30
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* [CommandLine] Error message for incorrect PositionalEatArgs usageKeno Fischer2018-05-141-9/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: bugpoint has several options specified as `PositionalEatArgs` to pass options through to the underlying tool, e.g. `-tool-args`. The `-help` message suggests the usage is: `-tool-args=<string>`. However, this is misleading, because that's not how these arguments work. Rather than taking a value, the option consumes all positional arguments until the next recognized option (or all arguments if `--` is specified at some point). To make this slightly clearer, instead print the help as: ``` -tool-args <string>... - <tool arguments>... ``` Additionally, add an error if the user attempts to use a `PositionalEatArgs` argument with a value, instead of silently ignoring it. Example: ``` ./bin/bugpoint -tool-args=-mpcu=skylake-avx512 bugpoint: for the -tool-args option: This argument does not take a value. Instead, it consumes any positional arguments until the next recognized option. ``` Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D46787 llvm-svn: 332311
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-146-116/+127
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [NFC] Remove inaccurate commentJF Bastien2018-05-121-3/+0
| | | | | | | | | | | | | | | Summary: r271558 moved getManagedStaticMutex's mutex from a function-local static to using call_once, but left a comment added in r211424. That comment is now erroneous, remove it. Reviewers: zturner, chandlerc Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46784 llvm-svn: 332175
* Remove unused SyncExecutor and make it clearer that the whole file is only ↵Nico Weber2018-05-111-14/+5
| | | | | | used if LLVM_ENABLE_THREADS llvm-svn: 332098
* [APFloat] Set losesInfo on no-op convertSven van Haastregt2018-05-111-1/+3
| | | | | | | | | | | | losesInfo would be left unset when no conversion needs to be done. A caller such as InstCombine's fitsInFPType would then branch on an uninitialized value. Caught using valgrind on an out-of-tree target. Differential Revision: https://reviews.llvm.org/D46645 llvm-svn: 332087
* [Support] Add docs for 'openFileFor{Write,Read}'Brian Gesiak2018-05-111-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add documentation for the LLVM Support functions `openFileForWrite` and `openFileForRead`. The `openFileForRead` parameter `RealPath`, in particular, I think warranted some explanation. In addition, make the behavior of the functions more consistent across platforms. Prior to this patch, Windows would set or not set the result file descriptor based on the nature of the error, whereas Unix would consistently set it to `-1` if the open failed. Make Windows consistently set it to `-1` as well. Test Plan: 1. `ninja check-llvm` 2. `ninja docs-llvm-html` Reviewers: zturner, rnk, danielmartin, scanon Reviewed By: danielmartin, scanon Subscribers: scanon, danielmartin, llvm-commits Differential Revision: https://reviews.llvm.org/D46499 llvm-svn: 332075
* [X86] ptwrite intrinsicGabor Buella2018-05-101-0/+5
| | | | | | | | | | Reviewers: craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D46539 llvm-svn: 331961
* APFloat/x87: Fix string conversion for "unnormal" values (pr35860)Pavel Labath2018-05-091-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Unnormal values are a feature of some very old x87 processors. We handle them correctly for the most part -- the only exception was an unnormal value whose significand happened to be zero. In this case the APFloat was still initialized as normal number (category = fcNormal), but a subsequent toString operation would assert because the math would produce nonsensical values for the zero significand. During review, it was decided that the correct way to fix this is to treat all unnormal values as NaNs (as that is what any >=386 processor will do). The issue was discovered because LLDB would crash when trying to print some "long double" values. Reviewers: skatkov, scanon, gottesmm Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41868 llvm-svn: 331884
* [Support/Path] Make handling of paths like "///" consistentPavel Labath2018-05-091-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Various path functions were not treating paths consisting of slashes alone consistently. For example, the iterator-based accessors decomposed the path "///" into two elements: "/" and ".". This is not too bad, but it is different from the behavior specified by posix: ``` A pathname that contains ***at least one non-slash character*** and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname. ``` More importantly, this was different from how we treated the same path in the filename+parent_path functions, which decomposed this path into "." and "". This was completely wrong as it lost the information that this was an absolute path which referred to the root directory. This patch fixes this behavior by making sure all functions treat paths consisting of (back)slashes alone the same way as "/". I.e., the iterator-based functions will just report one component ("/"), and the filename+parent_path will decompose them into "/" and "". A slightly controversial topic here may be the treatment of "//". Posix says that paths beginning with "//" may have special meaning and indeed we have code which parses paths like "//net/foo/bar" specially. However, as we were already not being consistent in parsing the "//" string alone, and any special parsing for it would complicate the code further, I chose to treat it the same way as longer sequences of slashes (which are guaranteed to be the same as "/"). Another slight change of behavior is in the parsing of paths like "//net//". Previously the last component of this path was ".". However, as in our parsing the "//net" part in this path was the same as the "drive" part in "c:\" and the next slash was the "root directory", it made sense to treat "//net//" the same way as "//net/" (i.e., not to add the extra "." component at the end). Reviewers: zturner, rnk, dblaikie, Bigcheese Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45942 llvm-svn: 331876
* [x86] Introduce the pconfig instructionGabor Buella2018-05-081-0/+12
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46430 llvm-svn: 331739
* Simplify LLVM_ATTRIBUTE_USED call sites.Fangrui Song2018-05-051-8/+3
| | | | llvm-svn: 331599
* Fix include of config.h that was incorrectly changed in r331184Justin Bogner2018-05-031-1/+1
| | | | | | | | | The RWMutex implementation depends on config.h macros (specifically HAVE_PTHREAD_H and HAVE_PTHREAD_RWLOCK_INIT), so we need to be including it and not just llvm-config.h here or we fall back to a much slower implementation. llvm-svn: 331487
OpenPOWER on IntegriCloud