summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* Reland [DWARF] Add a unit test for DWARFUnit::getLength().Igor Kudrin2019-09-101-0/+42
| | | | | | | | | | | This is a follow-up of rL369529, where the return value of DWARFUnit::getLength() was changed from uint32_t to uint64_t. The test checks that a unit header with Length > 4G can be successfully parsed and the value of the Length field is not truncated. Differential Revision: https://reviews.llvm.org/D67276 llvm-svn: 371510
* Revert "[DWARF] Add a unit test for DWARFUnit::getLength()" because it broke ↵Igor Kudrin2019-09-101-42/+0
| | | | | | ASAN bot. llvm-svn: 371505
* [DWARF] Add a unit test for DWARFUnit::getLength().Igor Kudrin2019-09-101-0/+42
| | | | | | | | | | | This is a follow-up of rL369529, where the return value of DWARFUnit::getLength() was changed from uint32_t to uint64_t. The test checks that a unit header with Length > 4G can be successfully parsed and the value of the Length field is not truncated. Differential Revision: https://reviews.llvm.org/D67276 llvm-svn: 371499
* [llvm][ADT][NFC] Add test for makeArrayRef(std::array)Jan Korous2019-09-101-0/+10
| | | | llvm-svn: 371475
* [Remarks] Add parser for bitstream remarksFrancis Visoiu Mistrih2019-09-092-0/+402
| | | | | | | | | | | | | | | | | | | | | | | | | | The bitstream remark serializer landed in r367372. This adds a bitstream remark parser that parser bitstream remark files to llvm::remarks::Remark objects through the RemarkParser interface. A few interesting things to point out: * There are parsing helpers to parse the different types of blocks * The main parsing helper allows us to parse remark metadata and open an external file containing the encoded remarks * This adds a dependency from the Remarks library to the BitstreamReader library * The testing strategy is to create a remark entry through YAML, parse it, serialize it to bitstream, parse that back and compare the objects. * There are close to no tests for malformed bitstream remarks, due to the lack of textual format for the bitstream format. * This adds a new C API for parsing bitstream remarks: LLVMRemarkParserCreateBitstream. * This bumps the REMARKS_API_VERSION to 1. Differential Revision: https://reviews.llvm.org/D67134 llvm-svn: 371429
* Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson2019-09-074-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
* [ORC][RPC] Join server thread before checking condition in unit test.Lang Hames2019-09-061-2/+2
| | | | | | Otherwise we have a race on the sent-messages count. llvm-svn: 371263
* [IR] CallBrInst: scan+update arg list when indirect dest list changesNick Desaulniers2019-09-061-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There's an unspoken invariant of callbr that the list of BlockAddress Constants in the "function args" list match the BasicBlocks in the "other labels" list. (This invariant is being added to the LangRef in https://reviews.llvm.org/D67196). When modifying the any of the indirect destinations of a callbr instruction (possible jump targets), we need to update the function arguments if the argument is a BlockAddress whose BasicBlock refers to the indirect destination BasicBlock being replaced. Otherwise, many transforms that modify successors will end up violating that invariant. A recent change to the arm64 Linux kernel exposed this bug, which prevents the kernel from booting. I considered maintaining a mapping from indirect destination BasicBlock to argument operand BlockAddress, but this ends up being a one to potentially many (though usually one) mapping. Also, the list of arguments to a function (or more typically inline assembly) ends up being less than 10. The implementation is significantly simpler to just rescan the full list of arguments. Because of the one to potentially many relationship, the full arg list must be scanned (we can't stop at the first instance). Thanks to the following folks that reported the issue and helped debug it: * Nathan Chancellor * Will Deacon * Andrew Murray * Craig Topper Link: https://bugs.llvm.org/show_bug.cgi?id=43222 Link: https://github.com/ClangBuiltLinux/linux/issues/649 Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html Reviewers: craig.topper, chandlerc Reviewed By: craig.topper Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D67252 llvm-svn: 371262
* [ORC] Add a missing #include atomic.Lang Hames2019-09-061-0/+1
| | | | | | Hopefully this will fix the bot build failures from r371245. llvm-svn: 371255
* GlobalISel: Add G_FMAD instructionMatt Arsenault2019-09-061-0/+4
| | | | llvm-svn: 371254
* [ORC] Make sure RPC channel-send is called in blocking calls and responses.Lang Hames2019-09-062-1/+44
| | | | | | | | | ORC-RPC batches calls by default, and the channel's send method must be called to transfer any buffered calls to the remote. The call to send was missing on responses and blocking calls in the SingleThreadedRPCEndpoint. This patch adds the necessary calls and modifies the RPC unit test to check for them. llvm-svn: 371245
* [FPEnv] Teach the IRBuilder about constrained FPToSI and FPToUI.Kevin P. Neal2019-09-061-0/+11
| | | | | | | | | | | | The IRBuilder doesn't know that the two floating point to integer instructions have constrained equivalents. This patch adds the support by building on the strict FP mode now present in the IRBuilder. Reviewed by: John McCall Approved by: John McCall Differential Revision: https://reviews.llvm.org/D67291 llvm-svn: 371235
* [Remarks] Add support for internalizing a remark in a string tableFrancis Visoiu Mistrih2019-09-061-0/+46
| | | | | | | | | | In order to keep remarks around, we need to make them tied to a string table. Users then can delete the parser and rely on the string table to keep the memory of the strings alive and deduplicated. llvm-svn: 371233
* [MC] Fix undefined behavior in MCInstPrinter::formatHexJonas Devlieghere2019-09-062-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing INT64_MIN to MCInstPrinter::formatHex triggers undefined behavior because the negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long long'). This patch puts a workaround in place to just print the hex value directly. A possible alternative involves using a small helper functions that uses (implementation) defined conversions to achieve the desirable value: static int64_t helper(int64_t V) { auto U = static_cast<uint64_t>(V); return V < 0 ? -U : U; } The underlying problem is that MCInstPrinter::formatHex(int64_t) returns a format_object<int64_t> and should really return a format_object<uint64_t>. However, that's not possible because formatImm needs to be able to print both as decimal (where a signed is required) and hex (where we'd prefer to always have an unsigned). format_object<int64_t> formatImm(int64_t Value) const { return PrintImmHex ? formatHex(Value) : formatDec(Value); } Differential revision: https://reviews.llvm.org/D67236 llvm-svn: 371159
* [Remarks] Add comparison operators to the Remark objectFrancis Visoiu Mistrih2019-09-052-0/+78
| | | | | | | | and related structs. This also adds tests for the remarks::Remark object in general. llvm-svn: 371134
* [globalisel][knownbits] Account for missing type constraintsDaniel Sanders2019-09-051-0/+26
| | | | | | | | | | | | | Now that we look through copies, it's possible to visit registers that have a register class constraint but not a type constraint. Avoid looking through copies when this occurs as the SrcReg won't be able to determine it's bit width or any known bits. Along the same lines, if the initial query is on a register that doesn't have a type constraint then the result is a default-constructed KnownBits, that is, a 1-bit fully-unknown value. llvm-svn: 371116
* [globalisel][knownbits] Correct a typo that prevented a test working as intendedDaniel Sanders2019-09-051-1/+1
| | | | llvm-svn: 371115
* [Remarks] Don't serialize metadata if a string table is not usedFrancis Visoiu Mistrih2019-09-051-10/+60
| | | | | | | For YAML remarks with no string table, the mode should not affect the output. llvm-svn: 371106
* [Support] Add writeFileAtomically() to FileUtilitiesJan Korous2019-09-052-0/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D66859 llvm-svn: 371103
* [globalisel] Support trivial COPY in GISelKnownBitsDaniel Sanders2019-09-041-0/+6
| | | | | | | | | | | | | | Summary: Allow GISelKnownBits to look through the trivial case of TargetOpcode::COPY Reviewers: aditya_nandakumar Subscribers: rovka, hiraditya, volkan, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67131 llvm-svn: 370955
* Add encode and decode methods to InlineInfo and document encoding format to ↵Greg Clayton2019-09-041-0/+136
| | | | | | | | | | the GSYM file format. This patch adds the ability to encode and decode InlineInfo objects and adds test coverage. Error handling is introduced in the encoding and decoding which will be used from here on out for remaining patches. Differential Revision: https://reviews.llvm.org/D66600 llvm-svn: 370936
* Skip MCJIT unit tests if LLVM is not configured for native compilationDavid Blaikie2019-09-031-1/+7
| | | | | | | | Patch by Sergej Jaskiewicz! Differential Revision: D67089 llvm-svn: 370812
* [FileCheck] Forbid using var defined on same lineThomas Preud'homme2019-09-021-41/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Commit r366897 introduced the possibility to set a variable from an expression, such as [[#VAR2:VAR1+3]]. While introducing this feature, it introduced extra logic to allow using such a variable on the same line later on. Unfortunately that extra logic is flawed as it relies on a mapping from variable to expression defining it when the mapping is from variable definition to expression. This flaw causes among other issues PR42896. This commit avoids the problem by forbidding all use of a variable defined on the same line, and removes the now useless logic. Redesign will be done in a later commit because it will require some amount of refactoring first for the solution to be clean. One example is the need for some sort of transaction mechanism to set a variable temporarily and from an expression and rollback if the CHECK pattern does not match so that diagnostics show the right variable values. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D66141 llvm-svn: 370663
* [SampleFDO] Add profile symbol list section to discriminate function beingWei Mi2019-08-311-0/+14
| | | | | | | | | | | | | | | | | | | cold versus function being newly added. This is the second half of https://reviews.llvm.org/D66374. Profile symbol list is the collection of function symbols showing up in the binary which generates the current profile. It is used to discriminate function being cold versus function being newly added. Profile symbol list is only added for profile with ExtBinary format. During profile use compilation, when profile-sample-accurate is enabled, a function without profile will be regarded as cold only when it is contained in that list. Differential Revision: https://reviews.llvm.org/D66766 llvm-svn: 370563
* [ADT] Removed VariadicFunctionDmitri Gribenko2019-08-302-110/+0
| | | | | | | | | | | | | | | Summary: It is not used. It uses macro-based unrolling instead of variadic templates, so it is not idiomatic anymore, and therefore it is a questionable API to keep "just in case". Subscribers: mgorny, dmgreen, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66961 llvm-svn: 370441
* GlobalISel: Add maskedValueIsZero and signBitIsZero to known bitsMatt Arsenault2019-08-291-0/+16
| | | | | | | I dropped the DemandedElts since it seems to be missing from some of the new interfaces, but not others. llvm-svn: 370389
* Fix for "DICompileUnit not listed in llvm.dbg.cu" verification error after ...Artur Pilipenko2019-08-281-0/+56
| | | | | | | | | | | | | | | | | | | ...cloning a function from a different module Currently when a function with debug info is cloned from a different module, the cloned function may have hanging DICompileUnits, so that the module with the cloned function fails debug info verification. The proposed fix inserts all DICompileUnits reachable from the cloned function to "llvm.dbg.cu" metadata operands of the cloned function module. Reviewed By: aprantl, efriedma Differential Revision: https://reviews.llvm.org/D66510 Patch by Oleg Pliss (Oleg.Pliss@azul.com) llvm-svn: 370265
* [IntrinsicEmitter] Support scalable vectors in intrinsicsCullen Rhodes2019-08-271-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for scalable vectors in intrinsics, enabling intrinsics such as the following to be defined: declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 4 x i32>) Support for this is implemented by defining a new type descriptor for scalable vectors and adding mangling support for scalable vector types in the name mangling scheme used by 'any' types in intrinsic signatures. Tests have been added for IRBuilder to test scalable vectors work as expected when using intrinsics through this interface. This required implementing an intrinsic that is explicitly defined with scalable vectors, e.g. LLVMType<nxv4i32>, an SVE floating-point convert intrinsic was used for this. The behaviour of the overloaded type LLVMScalarOrSameVectorWidth with scalable vectors is tested using the existing masked load intrinsic. Also added an .ll test to test the Verifier catches a bad intrinsic argument when passing a fixed-width predicate (mask) to the masked.load intrinsic where a scalable is expected. Patch by Paul Walker Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65930 llvm-svn: 370053
* Add error handling to the DataExtractor classPavel Labath2019-08-271-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is motivated by D63591, where we realized that there isn't a really good way of telling whether a DataExtractor is reading actual data, or is it just returning default values because it reached the end of the buffer. This patch resolves that by providing a new "Cursor" class. A Cursor object encapsulates two things: - the current position/offset in the DataExtractor - an error object Storing the error object inside the Cursor enables one to use the same pattern as the std::{io}stream API, where one can blindly perform a sequence of reads and only check for errors once at the end of the operation. Similarly to the stream API, as soon as we encounter one error, all of the subsequent operations are skipped (return default values) too, even if the would suceed with clear error state. Unlike the std::stream API (but in line with other llvm APIs), we force the error state to be checked through usage of llvm::Error. Reviewers: probinson, dblaikie, JDevlieghere, aprantl, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63713 llvm-svn: 370042
* [ORC] Make sure that queries on emitted-but-not-ready symbols fail correctly.Lang Hames2019-08-261-0/+54
| | | | | | | | | | | | | | | | | In r369808 the failure scheme for ORC symbols was changed to make MaterializationResponsibility objects responsible for failing the symbols they represented. This simplifies error logic in the case where symbols are still covered by a MaterializationResponsibility, but left a gap in error handling: Symbols that have been emitted but are not yet ready (due to a dependence on some unemitted symbol) are not covered by a MaterializationResponsibility object. Under the scheme introduced in r369808 such symbols would be moved to the error state, but queries on those symbols were never notified. This led to deadlocks when such symbols were failed. This commit updates error logic to immediately fail queries on any symbol that has already been emitted if one of its dependencies fails. llvm-svn: 369976
* [ORC] Fix an overly aggressive assert.Lang Hames2019-08-261-0/+29
| | | | | | | | Symbols that have not been queried will not have MaterializingInfo entries, so remove the assert that all failed symbols should have these entries. Also updates the loop to only remove entries that were found earlier. llvm-svn: 369975
* [ADT] Make StringRef(const char*) constexprBenjamin Kramer2019-08-262-1/+4
| | | | | | | | | | This should let us get rid of StringLiteral in the long term and avoid chasing accidental StringRef globals once and for all. This requires C++14, I godbolted it on every compiler I know we support so I hope there won't be much fallout. llvm-svn: 369961
* [ORC] Remove query dependencies when symbols are resolved.Lang Hames2019-08-231-1/+25
| | | | | | | | | | If the dependencies are not removed then a late failure (one symbol covered by the query failing after others have already been resolved) can result in an attempt to detach the query from already finalized symbol, resulting in an assert/crash. This patch fixes the issue by removing query dependencies in JITDylib::resolve for symbols that meet the required state. llvm-svn: 369809
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-232-52/+255
| | | | | | | | | | | | | When symbols are failed (via MaterializationResponsibility::failMaterialization) any symbols depending on them will now be moved to an error state. Attempting to resolve or emit a symbol in the error state (via the notifyResolved or notifyEmitted methods on MaterializationResponsibility) will result in an error. If notifyResolved or notifyEmitted return an error due to failure of a dependence then the caller should log or discard the error and call failMaterialization to propagate the failure to any queries waiting on the symbols being resolved/emitted (plus their dependencies). llvm-svn: 369808
* [SampleFDO] Add ExtBinary format to support extension of binary profile.Wei Mi2019-08-231-0/+8
| | | | | | | | | | | | This is a patch split from https://reviews.llvm.org/D66374. It tries to add a new format of profile called ExtBinary. The format adds a section header table to the profile and organize the profile in sections, so the future extension like adding a new section or extending an existing section will be easier while keeping backward compatiblity feasible. Differential Revision: https://reviews.llvm.org/D66513 llvm-svn: 369798
* [Support] Improve readNativeFile(Slice) interfacePavel Labath2019-08-222-16/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a subtle, but pretty important difference between the Slice and regular versions of this function. The Slice function was zero-initializing the rest of the buffer when the read syscall returned less bytes than expected, while the regular function did not. This patch removes the inconsistency by making both functions *not* zero-initialize the buffer. The zeroing code is moved to the MemoryBuffer class, which is currently the only user of this code. This makes the API more consistent, and the code shorter. While in there, I also refactor the functions to return the number of bytes through the regular return value (via Expected<size_t>) instead of a separate by-ref argument. Reviewers: aganea, rnk Subscribers: kristina, Bigcheese, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66471 llvm-svn: 369627
* Add FileWriter to GSYM and encode/decode functions to AddressRange and ↵Greg Clayton2019-08-211-1/+119
| | | | | | | | | | | | | | | | AddressRanges The full GSYM patch started with: https://reviews.llvm.org/D53379 This patch add the ability to encode data using the new llvm::gsym::FileWriter class. FileWriter is a simplified binary data writer class that doesn't require targets, target definitions, architectures, or require any other optional compile time libraries to be enabled via the build process. This class needs the ability to seek to different spots in the binary data that it produces to fix up offsets and sizes in GSYM data. It currently uses std::ostream over llvm::raw_ostream because llvm::raw_ostream doesn't support seeking which is required when encoding and decoding GSYM data. AddressRange objects are encoded and decoded to be relative to a base address. This will be the FunctionInfo's start address if the AddressRange is directly contained in a FunctionInfo, or a base address of the containing parent AddressRange or AddressRanges. This allows address ranges to be efficiently encoded using ULEB128 encodings as we encode the offset and size of each range instead of full addresses. This also makes encoded addresses easy to relocate as we just need to relocate one base address. Differential Revision: https://reviews.llvm.org/D63828 llvm-svn: 369587
* [BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida2019-08-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Tapi files are YAML files that start with the !tapi tag. The only execption are TBD v1 files, which don't have a tag. In that case we have to scan a little further and check if the first key "archs" exists. This is the first patch in a series of patches to add libObject support for text-based dynamic library (.tbd) files. This patch is practically exactly the same as D37820, that was never pushed to master, and is needed for future commits related to reading tbd files for llvm-nm Reviewers: ributzka, steven_wu, bollu, espindola, jfb, shafik, jdoerfert Reviewed By: steven_wu Subscribers: dexonsmith, llvm-commits Tags: #llvm, #clang, #sanitizers, #lldb, #libc, #openmp Differential Revision: https://reviews.llvm.org/D66149 llvm-svn: 369579
* reland [gtest] Fix printing of StringRef and SmallString in assert messages.Sam McCall2019-08-212-1/+15
| | | | | | | | | Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards the new features behind it. This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66. llvm-svn: 369527
* Revert "[gtest] Fix printing of StringRef and SmallString in assert messages."Sam McCall2019-08-212-15/+1
| | | | | | This reverts commit 4becb2ab4e9f52ce98272d1f5930d6942af5172b. llvm-svn: 369525
* [gtest] Fix printing of StringRef and SmallString in assert messages.Sam McCall2019-08-212-1/+15
| | | | | | | | | | | | | | | | | | Summary: These are detected by gtest as containers, and so previously printed as e.g. { '.' (46, 0x2E), 's' (115, 0x73), 'e' (101, 0x65), 'c' (99, 0x63), '0' (48, 0x30) }, gtest itself overloads PrintTo for std::string and friends, we use the same mechanism. Reviewers: labath Subscribers: dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66520 llvm-svn: 369518
* MinidumpYAML: move serialization code to MinidumpEmitter.cppPavel Labath2019-08-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The code for serializing minidumps was living in MinidumpYAML.cpp so that it would be accessible from unit tests. While this had its advantages, it was also unfortunate because it broke symmetry with all other yaml2obj serializers. Fortunately, nowadays all of yaml2obj is a library, so we don't need to do anything special. This patch improves the code consistency by moving the serialization code to MinidumpEmitter.cpp to match the style used in other backends. It also removes the writeAsBinary entry point in favor of the more general convertYAML interface. This patch is just massaging the code a bit. There shouldn't be any functional change here. Reviewers: jhenderson, abrachet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66474 llvm-svn: 369517
* Add TinyPtrVector support for general pointer-like things.Andrew Trick2019-08-202-9/+71
| | | | | | | | | | | | | | | In particular, make TinyPtrVector<PtrIntPair<T *, 1>> work. Remove all unnecessary assumptions that the element type has a formal "null" representation. The important property to maintain is that default-constructed element type has the same internal representation as the default-constructed PointerUnion (all zero bits). Remove the incorrect recursive behavior from PointerUnion::isNull. This was never generally correct because it only recursed over the first type parameter. With variadic templates it's completely unnecessary. llvm-svn: 369473
* Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"Pavel Labath2019-08-201-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | This recommits r368977, which was reverted in r369027 due to test failures in lldb. The cause of this was different behavior of readNativeFileSlice on windows and unix. These have been addressed in r369269. The original commit message was: In case the function was called with a desired read size *and* the file was not an "mmap()" candidate, the function was falling back to a "pread()", but it was failing to check the result of that system call. This meant that the function would return "success" even though the read operation failed, and it returned a buffer full of uninitialized memory. Reviewers: rnk, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66224 llvm-svn: 369370
* [cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFCHubert Tong2019-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL367756 (f5c40cb) increases the dependency of LLVMOrcJIT on LLVMPasses. In particular, symbols defined in LLVMPasses that are referenced by the destructor of `PassBuilder` are now referenced by LLVMOrcJIT through `Speculation.cpp.o`. We believe that referencing symbols defined in LLVMPasses in the destructor of `PassBuilder` is valid, and that adding to the set of such symbols is legitimate. To support such cases, this patch adds LLVMPasses to the set of libraries being linked when linking in LLVMOrcJIT causes such symbols from LLVMPasses to be referenced. Reviewers: Whitney, anhtuyen, pree-jackie Reviewed By: pree-jackie Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66441 llvm-svn: 369310
* Filesystem/Windows: fix inconsistency in readNativeFileSlice APIPavel Labath2019-08-191-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The windows version implementation of readNativeFileSlice, was trying to match the POSIX behavior of not treating EOF as an error, but it was only handling the case of reading from a pipe. Attempting to read past the end of a regular file returns a slightly different error code, which needs to be handled too. This patch adds ERROR_HANDLE_EOF to the list of error codes to be treated as an end of file, and adds some unit tests for the API. This issue was found while attempting to land D66224, which caused a bunch of lldb tests to start failing on windows. Reviewers: rnk, aganea Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66344 llvm-svn: 369269
* [ORC] Re-introduce self-dependence accidentally dropped from a unit test.Lang Hames2019-08-161-0/+1
| | | | llvm-svn: 369171
* [ADT] Remove llvm::make_unique utility.Jonas Devlieghere2019-08-161-1/+1
| | | | | | | | | | All uses of llvm::make_unique should have been replaced with std::make_unique. This patch represents the last part of the migration and removes the utility from LLVM. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 369130
* [TextAPI] Update reader to be supported by lib/ObjectCyndy Ishida2019-08-163-115/+98
| | | | | | | | | | | | | | | | | | | Summary: To be able to use the TextAPI/Reader for tbd file consumption (by libObject) it gets passed a MemoryBufferRef which isn't castable to MemoryBuffer. Updated the tests to expect that input as well. Reviewers: ributzka, steven_wu Reviewed By: steven_wu Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66147 llvm-svn: 369119
* Revert "MemoryBuffer: Add a missing error-check to getOpenFileImpl"Pavel Labath2019-08-151-51/+0
| | | | | | This reverts commit r368977 because it broke a couple of tests in lldb. llvm-svn: 369027
OpenPOWER on IntegriCloud