summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Fix a typo in Host.cpp that causes us to misidentify KNL, Silvermont, ↵Craig Topper2018-03-061-1/+1
| | | | | | | | | | Goldmont and probably other CPUs for -march=native I think most of the Intel Core CPUs and recent AMD CPUs are unaffected. All the CPUs that have a "subtype" should work. The ones that were broken are the ones that are a "type" with no subtypes. Fixes PR36619. llvm-svn: 326840
* PrintStatistics() and PrintStatisticsJSON() should take StatLockDaniel Sanders2018-03-061-0/+2
| | | | | | | | | | | | | | | | | | These two functions iterate over the list of statistics but don't take the lock that protects the iterators from being invalidated by StatisticInfo::addStatistic(). So far, this hasn't been an issue since (in-tree at least) these functions are called by the StatisticInfo destructor so addStatistic() shouldn't be called anymore. However, we do expose them in the public API. Note that this only protects against iterator invalidation and does not protect against ordering issues caused by statistic updates that race with PrintStatistics()/PrintStatisticsJSON(). Thanks to Roman Tereshin for spotting it llvm-svn: 326834
* [AMDGPU] Remove unused AMDOpenCL triple environmentTony Tye2018-03-051-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D43895 llvm-svn: 326745
* Re-commit: Make STATISTIC() values available programmaticallyDaniel Sanders2018-03-051-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It can be useful for tools to be able to retrieve the values of variables declared via STATISTIC() directly without having to emit them and parse them back. Use cases include: * Needing to report specific statistics to a test harness * Wanting to post-process statistics. For example, to produce a percentage of functions that were fully selected by GlobalISel Make this possible by adding llvm::GetStatistics() which returns an iterator_range that can be used to inspect the statistics that have been touched during execution. When statistics are disabled (NDEBUG and not LLVM_ENABLE_STATISTICS) this method will return an empty range. This patch doesn't address the effect of multiple compilations within the same process. In such situations, the statistics will be cumulative for all compilations up to the GetStatistics() call. Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner Reviewed By: rtereshin, bogner Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D43901 This re-commit fixes a missing include of <vector> which it seems clang didn't mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector only being forward declared at the point of use since it was fully defined eventually but G++/MSVC both rejected it at the point of use. llvm-svn: 326738
* On Windows we need to be able to process response files with Windows-styleDmitry Mikulin2018-03-051-1/+5
| | | | | | | | path names. Differential Revision: https://reviews.llvm.org/D43988 llvm-svn: 326737
* Revert r326723: Make STATISTIC() values available programmaticallyDaniel Sanders2018-03-051-25/+5
| | | | | | Despite building cleanly on my machine in three separate configs, it's failing on pretty much all bots due to missing includes among other things. Investigating. llvm-svn: 326726
* Make STATISTIC() values available programmaticallyDaniel Sanders2018-03-051-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It can be useful for tools to be able to retrieve the values of variables declared via STATISTIC() directly without having to emit them and parse them back. Use cases include: * Needing to report specific statistics to a test harness * Wanting to post-process statistics. For example, to produce a percentage of functions that were fully selected by GlobalISel Make this possible by adding llvm::GetStatistics() which returns an iterator_range that can be used to inspect the statistics that have been touched during execution. When statistics are disabled (NDEBUG and not LLVM_ENABLE_STATISTICS) this method will return an empty range. This patch doesn't address the effect of multiple compilations within the same process. In such situations, the statistics will be cumulative for all compilations up to the GetStatistics() call. Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner Reviewed By: rtereshin, bogner Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D43901 llvm-svn: 326723
* Make llvm::djbHash an inline function.Rui Ueyama2018-03-021-11/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D43644 llvm-svn: 326625
* Fix llvm-config --system-libs output on FreeBSD and NetBSDDimitry Andric2018-02-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For various reasons, CMake's detection mechanism for `backtrace()` returns an absolute path `/usr/lib/libexecinfo.so` on FreeBSD and NetBSD. Since `tools/llvm-config/CMakeLists.txt` only checks if system libraries start with `-`, this causes `llvm-config --system-libs` to produce the following incorrect output: ``` -lrt -l/usr/lib/libexecinfo.so -ltinfo -lpthread -lz -lm ``` Fix it by removing the path and the `lib` prefix, to make it look like a regular short library name, suitable for appending to a `-l` link flag. This also fixes the `Bindings/Go/go.test` test case, since that always died with "unable to find library -l/usr/lib/libexecinfo.so". Reviewers: chandlerc, emaste, joerg, krytarowski Reviewed By: krytarowski Subscribers: hans, bdrewery, mgorny, hintonda, llvm-commits Differential Revision: https://reviews.llvm.org/D42702 llvm-svn: 326358
* [ADT] Recognize ppc as valid architecture in target triple.Jonas Devlieghere2018-02-271-1/+1
| | | | | | | | | | | | | | | | Until this patch, only `powerpc` and `ppc32` were recognized as valid PowerPC 32-bit architectures in a target triple. This was incompatible with the triple `ppc-apple-darwin` as returned for libObject. I found out about this when working on a test case using a binary generated on an old PowerBook G4. We had the choice of either fix this in the Mach-O object parser or in the Triple implementation. I chose the latter because it feels like the most canonical place. Differential revision: https://reviews.llvm.org/D43760 llvm-svn: 326182
* Re-land: "[Support] Replace HashString with djbHash."Jonas Devlieghere2018-02-261-19/+20
| | | | | | | | | | | | | | | | | | | | | This patch removes the HashString function from StringExtraces and replaces its uses with calls to djbHash from DJB.h. This change is *almost* NFC. While the algorithm is identical, the djbHash implementation in StringExtras used 0 as its default seed while the implementation in DJB uses 5381. The latter has been shown to result in less collisions and improved avalanching and is used by the DWARF accelerator tables. Because some test were implicitly relying on the hash order, I've reverted to using zero as a seed for the following two files: lld/include/lld/Core/SymbolTable.h llvm/lib/Support/StringMap.cpp Differential revision: https://reviews.llvm.org/D43615 llvm-svn: 326091
* Test commitDavid Zarzycki2018-02-261-1/+0
| | | | llvm-svn: 326085
* Revert "[Support] Replace HashString with djbHash."Jonas Devlieghere2018-02-261-20/+19
| | | | | | | | | | | | | It looks like some of our tests depend on the ordering of hashed values. I'm reverting my changes while I try to reproduce and fix this locally. Failing builds: lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/18388 lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6743 lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15607 llvm-svn: 326082
* [Support] Replace HashString with djbHash.Jonas Devlieghere2018-02-261-19/+20
| | | | | | | | | | | | | | | This removes the HashString function from StringExtraces and replaces its uses with calls to djbHash from DJB.h This is *almost* NFC. While the algorithm is identical, the djbHash implementation in StringExtras used 0 as its seed while the implementation in DJB uses 5381. The latter has been shown to result in less collisions and improved avalanching. https://reviews.llvm.org/D43615 (cherry picked from commit 77f7f965bc9499a9ae768a296ca5a1f7347d1d2c) llvm-svn: 326081
* llvm-config: Add advapi32 to --system-libs on Windows (PR36372)Hans Wennborg2018-02-231-1/+2
| | | | llvm-svn: 325894
* Resubmit r325107 (case folding DJB hash)Pavel Labath2018-02-213-2/+821
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue was that the has function was generating different results depending on the signedness of char on the host platform. This commit fixes the issue by explicitly using an unsigned char type to prevent sign extension and adds some extra tests. The original commit message was: This patch implements a variant of the DJB hash function which folds the input according to the algorithm in the Dwarf 5 specification (Section 6.1.1.4.5), which in turn references the Unicode Standard (Section 5.18, "Case Mappings"). To achieve this, I have added a llvm::sys::unicode::foldCharSimple function, which performs this mapping. The implementation of this function was generated from the CaseMatching.txt file from the Unicode spec using a python script (which is also included in this patch). The script tries to optimize the function by coalescing adjecant mappings with the same shift and stride (terms I made up). Theoretically, it could be made a bit smarter and merge adjecant blocks that were interrupted by only one or two characters with exceptional mapping, but this would save only a couple of branches, while it would greatly complicate the implementation, so I deemed it was not worth it. Since we assume that the vast majority of the input characters will be US-ASCII, the folding hash function has a fast-path for handling these, and only whips out the full decode+fold+encode logic if we encounter a character outside of this range. It might be possible to implement the folding directly on utf8 sequences, but this would also bring a lot of complexity for the few cases where we will actually need to process non-ascii characters. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: mgorny, hintonda, echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D42740 llvm-svn: 325732
* Report fatal error in the case of out of memorySerge Pavlov2018-02-204-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
* [Support] Replace hand-written scope_exit with make_scope_exit.Benjamin Kramer2018-02-181-23/+3
| | | | | | No functionality change intended. llvm-svn: 325460
* [X86] Add 'sahf' to getHostCPUFeatures so -march=native will pick it up ↵Craig Topper2018-02-171-0/+1
| | | | | | | | | | | | | | | | correctly. Summary: We probably mostly get this right due to family/model/stepping mapping to CPU names. But we should detect it explicitly. Reviewers: RKSimon, echristo, dim, spatel Reviewed By: dim Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43418 llvm-svn: 325439
* Report fatal error in the case of out of memorySerge Pavlov2018-02-171-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | This is partial recommit of r325224, reverted in 325227. The relevant part of original comment is below. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325426
* [APInt] Fix extractBits to correctly handle Result.isSingleWord() case.Tim Shen2018-02-161-1/+2
| | | | | | | | | | | | Summary: extractBits assumes that `!this->isSingleWord() implies !Result.isSingleWord()`, which may not necessarily be true. Handle both cases. Reviewers: RKSimon Subscribers: sanjoy, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43363 llvm-svn: 325311
* Silence warning about unused private variable.Zachary Turner2018-02-151-1/+3
| | | | llvm-svn: 325275
* Call FlushFileBuffers on output files.Zachary Turner2018-02-151-1/+15
| | | | | | | | | | | | There is a latent Windows kernel bug, the exact trigger conditions are not well understood, which can cause a file to be correctly written, but unable to be correctly read. The workaround appears to be simply calling FlushFileBuffers. Differential Revision: https://reviews.llvm.org/D42925 llvm-svn: 325274
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-156-45/+13
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Specify namespace for reallocSerge Pavlov2018-02-151-1/+1
| | | | llvm-svn: 325226
* Report fatal error in the case of out of memorySerge Pavlov2018-02-156-13/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* Revert r325107 (case folding DJB hash) and subsequent build fixPavel Labath2018-02-143-820/+1
| | | | | | | The "knownValuesUnicode" test in the patch fails on ppc64 and arm64 bots. Reverting while I investigate. llvm-svn: 325115
* Implement a case-folding version of DJB hashPavel Labath2018-02-143-1/+820
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a variant of the DJB hash function which folds the input according to the algorithm in the Dwarf 5 specification (Section 6.1.1.4.5), which in turn references the Unicode Standard (Section 5.18, "Case Mappings"). To achieve this, I have added a llvm::sys::unicode::foldCharSimple function, which performs this mapping. The implementation of this function was generated from the CaseMatching.txt file from the Unicode spec using a python script (which is also included in this patch). The script tries to optimize the function by coalescing adjecant mappings with the same shift and stride (terms I made up). Theoretically, it could be made a bit smarter and merge adjecant blocks that were interrupted by only one or two characters with exceptional mapping, but this would save only a couple of branches, while it would greatly complicate the implementation, so I deemed it was not worth it. Since we assume that the vast majority of the input characters will be US-ASCII, the folding hash function has a fast-path for handling these, and only whips out the full decode+fold+encode logic if we encounter a character outside of this range. It might be possible to implement the folding directly on utf8 sequences, but this would also bring a lot of complexity for the few cases where we will actually need to process non-ascii characters. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: mgorny, hintonda, echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D42740 llvm-svn: 325107
* Fix off-by-one in set_thread_name which causes truncation to fail on LinuxSam McCall2018-02-131-1/+2
| | | | llvm-svn: 325069
* Make LLVM timer reprintable: that is, make more than one print action on the ↵George Karpenkov2018-02-101-2/+10
| | | | | | | | | | | | | | | | same timer feasible Currently, each LLVM timer can be only printed once, as the act of printing clears the timer. Moreover, the current printing mechanism implicitly assumes that the timer is stopped -- and prints zero otherwise. This patch relaxes this assumption and makes printing statistics multiple time a possibility. Differential Revision: https://reviews.llvm.org/D43136 llvm-svn: 324788
* [ARM] Add 'fillValidCPUArchList' to ARM targetsErich Keane2018-02-081-0/+14
| | | | | | | | | This is a support change for a CFE change (https://reviews.llvm.org/D42978) that allows march and -target-cpu to list the valid targets in a note. The changes are limited to the ARM/AArch64, since this is the only target that gets the CPU list from LLVM. llvm-svn: 324623
* [ADT] Replace sys::MemoryFence with standard atomics.Benjamin Kramer2018-02-011-6/+2
| | | | | | | | This is a bit faster in theory, in practice it's cold code that's only active in !NDEBUG, so it probably doesn't make a difference. This is one of the last users of our homegrown Atomic.h. llvm-svn: 323999
* Add more initializers to quiet a clang warningDaniel Sanders2018-01-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `struct crashreporter_annotations_t` gained one more `uint64_t` field in `CRASHREPORTER_ANNOTATIONS_VERSION` 5 causing an annoying clang warning: ``` llvm/lib/Support/PrettyStackTrace.cpp:92:65: warning: missing field 'abort_cause' initializer [-Wmissing-field-initializers] = { CRASHREPORTER_ANNOTATIONS_VERSION, 0, 0, 0, 0, 0, 0 }; ^ 1 warning generated ``` Let's fix it. Patch by Roman Tereshin Reviewers: qcolombet, echristo, beanz, dexonsmith Reviewed By: echristo Subscribers: dsanders, dexonsmith, beanz, echristo, qcolombet, llvm-commits Differential Revision: https://reviews.llvm.org/D42268 llvm-svn: 323777
* [Support] Move DJB hash to support. NFCJonas Devlieghere2018-01-282-0/+21
| | | | | | | | | | | This patch moves the DJB hash to support. This is consistent with other hashing algorithms living there. The hash is used by the DWARF accelerator tables. We're doing this now because the hashing function is needed by dsymutil and we don't want to link against libBinaryFormat. Differential revision: https://reviews.llvm.org/D42594 llvm-svn: 323616
* [Support] Move PrintEscapedString into the library its declaration is inBenjamin Kramer2018-01-261-0/+10
| | | | llvm-svn: 323558
* [WebAssembly] Switch to *-wasm as the default target triple.Dan Gohman2018-01-231-2/+4
| | | | | | | | This makes wasm32-unknown-unknown-wasm the default, which supports the .o file writer and the new linking ABI. To enable s2wasm-compatible output, use the wasm32-unknown-unknown-elf triple. llvm-svn: 323220
* Revert r322595: Specify inline for isWhitespace in CommandLine.cppRui Ueyama2018-01-221-1/+1
| | | | | | | | | The original change was made based on a misunderstanding that -DCMAKE_BUILD_TYPE=RelWithDebugInfo would produce the same executable as -DCMAKE_BUILD_TYPE=Release modulo debug info. Turned out that's not true -- it at least disables some optimizations such as function inlining. llvm-svn: 323161
* Fallback option for colorized output when terminfo isn't availablePetr Hosek2018-01-191-0/+15
| | | | | | | | | | | Try to detect the terminal color support by checking the value of the TERM environment variable. This is not great, but it's better than nothing when terminfo library isn't available, which may still be the case on some Linux distributions. Differential Revision: https://reviews.llvm.org/D42055 llvm-svn: 322962
* [X86] Add intrinsic support for the RDPID instructionCraig Topper2018-01-181-1/+3
| | | | | | | | This adds a new instrinsic to support the rdpid instruction. The implementation is a bit weird because the intrinsic is defined as always returning 32-bits, but the assembler support thinks the instruction produces a 64-bit register in 64-bit mode. But really it zeros the upper 32 bits. So I had to add separate patterns where 64-bit mode uses an extract_subreg. Differential Revision: https://reviews.llvm.org/D42205 llvm-svn: 322910
* Typo fix SIBABRT -> SIGABRT.Eric Christopher2018-01-181-1/+1
| | | | | | Based on a patch by Henry Wong! llvm-svn: 322902
* Support: Add missing #include.Peter Collingbourne2018-01-181-0/+2
| | | | | | | This #include is necessary to provide the definitions of _fpclass and _FPCLASS_NZ when building with libc++. llvm-svn: 322885
* [Support] Return an enum instead of an unsigned; NFC.George Burgess IV2018-01-171-2/+2
| | | | | | | | | | | | | | We seem to be (logically) returning ArchExtKinds here in all cases, so the return type should reflect that. The static_cast is necessary because `A.ID` is actually an `unsigned`, presumably since we use `decltype(A)` to represent extended attributes for both ARM and AArch64, which use distinct `ArchExtKinds`. We can't trivially make the same change for ARM, because one of the values it returns is the bitwise-or of two `ARM::ArchExtKind`s. llvm-svn: 322613
* Specify inline for isWhitespace in CommandLine.cppRui Ueyama2018-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Takuto Ikuta. In chromium's component build, there are many directive sections and commandline parsing takes much time. This patch is for speed up of lld in RelWithDebInfo build by forcing inline heavily called isWhitespace function. 10 times link perf stats of blink_core.dll changed like below. master: TotalSeconds: 9.8764878 TotalSeconds: 10.1455242 TotalSeconds: 10.075279 TotalSeconds: 10.3397347 TotalSeconds: 9.8361665 TotalSeconds: 9.9544441 TotalSeconds: 9.8960686 TotalSeconds: 9.8877865 TotalSeconds: 10.0551879 TotalSeconds: 10.0492254 Avg: 10.01159047 with this patch: TotalSeconds: 8.8696762 TotalSeconds: 9.1021585 TotalSeconds: 9.0233893 TotalSeconds: 9.1886175 TotalSeconds: 9.156954 TotalSeconds: 9.0978564 TotalSeconds: 9.1316824 TotalSeconds: 8.8354606 TotalSeconds: 9.2549431 TotalSeconds: 9.4473085 Avg: 9.11080465 llvm-svn: 322595
* [Support] Remove MemoryBuffer::getNewMemBufferPavel Labath2018-01-151-5/+0
| | | | | | | all callers have been switched the the Writable version (which does not require const_casting to be useful). llvm-svn: 322475
* [TargetParser] Add missing armv8l ARMv8 variant.Florian Hahn2018-01-091-1/+1
| | | | | | | | | | | | | | | | | | This change adds the missing armv8l variant as an alias of armv8 architecture. The issue was observed with several regressions in validation on armv8l hardware (for instance ExecutionEngine/frem.ll failed due to lack of neon fpu). Tested with regression testsuite passed without regression on ARM and x86_64. Patch by Yvan Roux. Reviewers: rengolin, rogfer01, olista01, fhahn Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D41859 llvm-svn: 322098
* [Support] Use realpath(3) instead of trying to open a file.Davide Italiano2018-01-091-6/+6
| | | | | | | | | If we don't have read permissions on the directory the call would fail. <rdar://problem/35871293> llvm-svn: 322095
* [Support] Add WritableMemoryBuffer::getNewMemBufferPavel Labath2018-01-091-5/+10
| | | | | | | | | | | | | | | | | | Summary: The idea is that it would replace (non-Writable)MemoryBuffer::getNewMemBuffer, which is quite useless unless you const_cast its contents to write to it (which all (both) callers of this function were doing). This patch also fixes one of the usages in COFFWriter. After fixing the other usage in clang, I plan to delete the old function. Reviewers: dblaikie, Bigcheese Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41540 llvm-svn: 322094
* Added support for reading configuration filesSerge Pavlov2017-12-301-0/+48
| | | | | | | | | | | | | Configuration file is read as a response file in which file names in the nested constructs `@file` are resolved relative to the directory where the including file resides. Lines in which the first non-whitespace character is '#' are considered as comments and are skipped. Trailing backslashes are used to concatenate lines in the same way as they are used in shell scripts. Differential Revision: https://reviews.llvm.org/D24926 llvm-svn: 321586
* Reverted 321580: Added support for reading configuration filesSerge Pavlov2017-12-301-47/+0
| | | | | | It caused buildbot fails. llvm-svn: 321582
* Added support for reading configuration filesSerge Pavlov2017-12-301-0/+47
| | | | | | | | | | | | | Configuration file is read as a response file in which file names in the nested constructs `@file` are resolved relative to the directory where the including file resides. Lines in which the first non-whitespace character is '#' are considered as comments and are skipped. Trailing backslashes are used to concatenate lines in the same way as they are used in shell scripts. Differential Revision: https://reviews.llvm.org/D24926 llvm-svn: 321580
OpenPOWER on IntegriCloud