summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* [Unittests] Change linker flags of dynamic library testsMikhail Maltsev2018-06-111-1/+8
| | | | | | | | | | | | | | | | | | | A recent change https://reviews.llvm.org/D46898 which had no intended behavior change, actually modified the linker flags used when linking the dynamic libraries used by the DynamicLibraryTests unit test. This made the test fail in our testing environment which runs the tests from an NFS share. Prior to D46898 the two libraries used by the test were different (because the library name used to be embedded into the binary), and after the change they became bit-to-bit identical. This causes dlopen to return the same handle when these two libraries are loaded from an NFS share, and the test expects two different handles. This patch reverts the part of D46898 that is responsible for changing the linker flags. Differential Revision: https://reviews.llvm.org/D47469 llvm-svn: 334394
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-074-5/+228
| | | | | | | | | | | | | | | | | 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
* [AArch64, ARM] Add support for Samsung Exynos M4Evandro Menezes2018-06-061-8/+19
| | | | | | Create a separate feature set for Exynos M4 and add test cases. llvm-svn: 334115
* [YAML] Quote multiline string scalarsIlya Biryukov2018-05-301-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Otherwise, the YAML parser breaks when trying to read them back in 'key: multiline_string_value' cases. This patch fixes a problem when serializing structs which contain multi-line strings. E.g., if we try to serialize the following struct ``` { "key1": "first line\nsecond line", "key2": "another string" }` ``` Before this patch, we got the YAML output that failed to parse: ``` key1: first line second line key2: another string ``` After the patch, we get: ``` key1: 'first line second line' key2: another string ``` Reviewers: sammccall Reviewed By: sammccall Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47468 llvm-svn: 333527
* Support: Simplify endian stream interface. NFCI.Peter Collingbourne2018-05-181-11/+11
| | | | | | | | | | | | Provide some free functions to reduce verbosity of endian-writing a single value, and replace the endianness template parameter with a field. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47032 llvm-svn: 332757
* use standard llvm cmake formatting for targets defined in plugin testsNico Weber2018-05-181-3/+9
| | | | llvm-svn: 332709
* Revert 332508 as it caused problems in the clang test suite.Greg Clayton2018-05-161-3/+2
| | | | llvm-svn: 332555
* Fix llvm::sys::path::remove_dots() to return "." instead of an empty path.Greg Clayton2018-05-161-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D46887 llvm-svn: 332508
* Give shared modules in unittests the platform-native extension, make ↵Nico Weber2018-05-162-12/+7
| | | | | | | | | | | | | | | | | PipSqueak a MODULE As far as I can tell from revision history, there's no good reason to call these files .so instead of .dll in Windows, so use the normal extension. Also change PipSquak from SHARED to MODULE -- it's never passed to target_link_libraries() and only loaded via dlopen(), so MODULE is more appropriate. This makes it possible to delete a workaround for SHARED ldflags being not quite right as well. No intended behavior change. https://reviews.llvm.org/D46898 llvm-svn: 332487
* Use perfect forwarding to deduplicate code in unit test. NFC.Benjamin Kramer2018-05-151-22/+2
| | | | llvm-svn: 332388
* Rename three cxx files in unittests to cpp.Nico Weber2018-05-153-5/+8
| | | | | | | | | | | | LLVM uses cpp as its C++ file extension, these are the only three cxx file in the monorepo. These files apparently were called to escape a CMake check -- use the LLVM_OPTIONAL_SOURCES mechanism that's meant as an escape for this case instead. No intended behavior change. https://reviews.llvm.org/D46843 llvm-svn: 332368
* Fix broken asan Support testsEric Liu2018-05-151-8/+14
| | | | | | | | The asan failures were caught in google internal asan tests after r332311 o Make StackOption support cl::list o Rememeber to removeArguments for cl::alias in tests. llvm-svn: 332354
* [CommandLine] Error message for incorrect PositionalEatArgs usageKeno Fischer2018-05-141-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Support/Path] Make handling of paths like "///" consistentPavel Labath2018-05-091-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-012-2/+2
| | | | | | | | | | | | | | | | 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 Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-303-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-295-22/+22
| | | | | | | | | | | | | | 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
* [Support/Path] Add more tests and improve failure messages of existing onesPavel Labath2018-04-241-102/+52
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I am preparing a patch to the path function. While working on it, I noticed that some of the areas are lacking test coverage (e.g. filename and parent_path functions), so I add more tests to guard against regressions there. I have also found the failure messages hard to understand, so I rewrote some existing test to give more actionable messages when they fail: - for tests which run over multiple inputs, I use SCOPED_TRACE, to show which of the inputs caused the actual failure. - for comparisons of vectors, I use gmock's container matchers, which will print out the full container contents (and the elements that differ) when they fail to match. Reviewers: zturner, espindola Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45941 llvm-svn: 330691
* [Testing/Support] Make Failed() matcher work with abstract error typesPavel Labath2018-04-101-0/+1
| | | | | | | | | | | | Failed<ErrorInfoBase>() did not compile, because it was attempting to create a copy of the Error object when passing it to the nested matcher, which was not possible because ErrorInfoBase is abstract. This commit fixes the problem by making sure we pass the ErrorInfo object by reference, which also improves the handling of non-abstract objects, as we avoid potentially slicing an object during the copy. llvm-svn: 329703
* Fix stack-use-after-scope in test previously hidden by -fmerge-all-constantsVitaly Buka2018-04-071-3/+3
| | | | llvm-svn: 329489
* [unittests] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-071-6/+6
| | | | | | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. llvm-svn: 329475
* [Support] Make line-number cache robust against access patterns.Graydon Hoare2018-04-071-0/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang) has a routine for looking up line numbers of SMLocs. This routine uses a shared, special-purpose cache that handles exactly one access pattern efficiently: looking up the line number of an SMLoc that points into the same buffer as the last query made to the SourceMgr, at a location in the buffer at or ahead of the last query. When this works it's fine, but when it fails it's catastrophic for performancer: one recent out-of-order access from a Swift utility routine ran for tens of seconds, spending 99% of its time repeatedly scanning buffers for '\n'. This change removes the shared cache from the SourceMgr and installs a new cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense that rather than caching a single last-query pointer, they cache _all_ the line-ending offsets, in a binary-searchable array, such that once it's populated (on first access), all subsequent access patterns run at the same speed. Performance measurements I've done show this is actually a little bit faster on real codebases (though only a couple fractions of a percent). Memory usage is up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done on it; I've attempted to minimize this by using dynamic selection of integer sized when storing offset arrays. But the main motive here is to make-impossible the cases we don't always see, that show up by surprise when there is an out-of-order access pattern. Reviewers: jordan_rose Reviewed By: jordan_rose Subscribers: probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45003 llvm-svn: 329470
* [llvm-cov] Prevent llvm-cov from hanging when a symblink doesn't exist.Max Moroz2018-04-051-40/+73
| | | | | | | | | | | | | | | | | | | | Summary: Previous code hangs indefinitely when trying to iterate through a symbol link file that points to an non-exist directory. This change fixes the bug to make the addCollectedPath function exit ealier and print out correct warning messages. Patch by Yuke Liao (@liaoyuke). Reviewers: Dor1s, vsk Reviewed By: vsk Subscribers: bruno, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D44960 llvm-svn: 329338
* [Testing/Support]: Better matching of Error failure statesPavel Labath2018-04-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The existing Failed() matcher only allowed asserting that the operation failed, but it was not possible to verify any details of the returned error. This patch adds two new matchers, which make this possible: - Failed<InfoT>() verifies that the operation failed with a single error of a given type. - Failed<InfoT>(M) additionally check that the contained error info object is matched by the nested matcher M. To make these work, I've changed the implementation of the ErrorHolder class. Now, instead of just storing the string representation of the Error, it fetches the ErrorInfo objects and stores then as a list of shared pointers. This way, ErrorHolder remains copyable, while still retaining the full information contained in the Error object. In case the Error object contains two or more errors, the new matchers will fail to match, instead of trying to match all (or any) of the individual ErrorInfo objects. This seemed to be the most sensible behavior for when one wants to match exact error details, but I could be convinced otherwise... Reviewers: zturner, lhames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44925 llvm-svn: 329288
* [YAML] Remove unit test of multibyte non-printable escaping that uses C++11 ↵Graydon Hoare2018-03-271-1/+0
| | | | | | escapes llvm-svn: 328665
* [YAML] Escape non-printable multibyte UTF8 in Output::scalarString.Graydon Hoare2018-03-271-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing YAML Output::scalarString code path includes a partial and incorrect implementation of YAML escaping logic. In particular, the logic put in place in rL321283 escapes non-printable bytes only if they are not part of a multibyte UTF8 sequence; implicitly this means that all multibyte UTF8 sequences -- printable and non -- are passed through verbatim. The simplest solution to this is to direct the Output::scalarString method to use the standalone yaml::escape function, and this _almost_ works, except that the existing code in that function _over_ escapes: any multibyte UTF8 sequence is escaped, even printable ones. While this is permitted for YAML, it is also more aggressive (and hard to read for non-English locales) than necessary, and the entire point of rL321283 was to back off such aggressive over-escaping. So in this change, I have both redirected Output::scalarString to use yaml::escape _and_ modified yaml::escape to optionally restrict its escaping to non-printables. This preserves behaviour of any existing clients while giving them a path to more moderate escaping should they desire. Reviewers: JDevlieghere, thegameg, MatzeB, vladimir.plyashkun Reviewed By: thegameg Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44863 llvm-svn: 328661
* [Support] Pacify -Wsign-compare in unit test.Benjamin Kramer2018-03-081-2/+2
| | | | llvm-svn: 327070
* [Support] Add WriteThroughMemoryBuffer.Zachary Turner2018-03-081-0/+29
| | | | | | | | | | | This is like MemoryBuffer (read-only) and WritableMemoryBuffer (writable private), but where the underlying file can be modified after writing. This is useful when you want to open a file, make some targeted edits, and then write it back out. Differential Revision: https://reviews.llvm.org/D44230 llvm-svn: 327057
* On Windows we need to be able to process response files with Windows-styleDmitry Mikulin2018-03-051-0/+35
| | | | | | | | path names. Differential Revision: https://reviews.llvm.org/D43988 llvm-svn: 326737
* Utility functions for checked arithmeticGeorge Karpenkov2018-03-022-0/+72
| | | | | | | | | Provide checkedAdd and checkedMul functions, providing checked arithmetic on signed integers. Differential Revision: https://reviews.llvm.org/D43704 llvm-svn: 326516
* Resubmit r325107 (case folding DJB hash)Pavel Labath2018-02-212-0/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-202-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-152-5/+3
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Report fatal error in the case of out of memorySerge Pavlov2018-02-152-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-142-90/+0
| | | | | | | The "knownValuesUnicode" test in the patch fails on ppc64 and arm64 bots. Reverting while I investigate. llvm-svn: 325115
* Fix build broken by r325107Pavel Labath2018-02-141-23/+23
| | | | | | | Older gcc versions need an extra pair of {}s to convert a string literal into llvm::StringLiteral. llvm-svn: 325109
* Implement a case-folding version of DJB hashPavel Labath2018-02-142-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 signed/unsigned compare warning I introducedErich Keane2018-02-081-2/+2
| | | | | | | | 'size' of a vector is unsigned, and I accidentially compared it to an int through GTEST. I switched it to unsigned, which is the template parameter type anyway. llvm-svn: 324625
* [ARM] Add 'fillValidCPUArchList' to ARM targetsErich Keane2018-02-081-0/+28
| | | | | | | | | 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
* Fix incorrect usage of std::is_assignable.Richard Smith2018-02-021-2/+2
| | | | | | We want to check that we can assign to an lvalue here, not a prvalue. llvm-svn: 324152
* [YAML] Plain scalars can not begin with most indicators.Haojian Wu2018-01-221-0/+4
| | | | | | | | | | | | | | | | | | | Summary: Discovered when clangd loads YAML symbols, some symbol documentations start with indicators (e.g. "-"), but YAML prints them as plain scalars (no quotes), which make the YAML parser fail to parse. For these kind of strings, we need quotes. Reviewers: sammccall Reviewed By: sammccall Subscribers: ilya-biryukov, ioeric, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D42362 llvm-svn: 323097
* [TargetParser] Add missing armv8l ARMv8 variant.Florian Hahn2018-01-091-17/+18
| | | | | | | | | | | | | | | | | | 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-0/+19
| | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | 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/+133
| | | | | | | | | | | | | 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-133/+0
| | | | | | It caused buildbot fails. llvm-svn: 321582
* Added support for reading configuration filesSerge Pavlov2017-12-301-0/+133
| | | | | | | | | | | | | 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
* Unbreak the build. Combining chrono with Optional is annoying.Benjamin Kramer2017-12-221-2/+2
| | | | llvm-svn: 321387
* [YAML] Refactor escaping unittestsFrancis Visoiu Mistrih2017-12-211-111/+24
| | | | llvm-svn: 321284
* [YAML] Fix UTF-8 handlingFrancis Visoiu Mistrih2017-12-211-0/+28
| | | | | | | | Previous YAML quoting patches broke UTF-8 printing in YAML: see https://reviews.llvm.org/D41290#961801. Differential Revision: https://reviews.llvm.org/D41490 llvm-svn: 321283
OpenPOWER on IntegriCloud