aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/Bitcode
AgeCommit message (Collapse)AuthorFilesLines
2014-11-13[Bitcode] AtEndOfStream should only check against the size if it's known.Jordan Rose2-0/+57
This avoids an issue where AtEndOfStream mistakenly returns true at the /start/ of a stream. (In the rare case that the size is known and actually 0, the slow path will still handle it correctly.) llvm-svn: 221840
2014-10-24Modernize the error handling of the Materialize function.Rafael Espindola1-3/+3
llvm-svn: 220600
2014-09-23Do not destroy external linkage when deleting function bodyPetar Jovanovic1-0/+24
The function deleteBody() converts the linkage to external and thus destroys original linkage type value. Lack of correct linkage type causes wrong relocations to be emitted later. Calling dropAllReferences() instead of deleteBody() will fix the issue. Differential Revision: http://reviews.llvm.org/D5415 llvm-svn: 218302
2014-09-03Pass a && to getLazyBitcodeModule.Rafael Espindola1-1/+2
This forces callers to use std::move when calling it. It is somewhat odd to have code with std::move that doesn't always move, but it is also odd to have code without std::move that sometimes moves. llvm-svn: 217049
2014-08-27Return a std::unique_ptr when creating a new MemoryBuffer.Rafael Espindola1-2/+2
llvm-svn: 216583
2014-08-26Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.Rafael Espindola1-1/+2
By taking a reference we can do the ownership transfer in one place instead of expecting every caller to do it. llvm-svn: 216492
2014-08-19Modernize the .ll parsing interface.Rafael Espindola1-5/+3
* Use StringRef instead of std::string& * Return a std::unique_ptr<Module> instead of taking an optional module to write to (was not really used). * Use current comment style. * Use current naming convention. llvm-svn: 215989
2014-08-02BitcodeTests: Fix LINK_COMPONENTS.NAKAMURA Takumi2-2/+3
llvm-svn: 214598
2014-08-01BitcodeReader: Fix some BlockAddress forward reference corner casesDuncan P. N. Exon Smith1-0/+68
`BlockAddress`es are interesting in that they can reference basic blocks from *outside* the block's function. Since basic blocks are not global values, this presents particular challenges for lazy parsing. One corner case was found in PR11677 and fixed in r147425. In that case, a global variable references a block address. It's necessary to load the relevant function to resolve the forward reference before doing anything with the module. By inspection, I found (and have fixed here) two other cases: - An instruction from one function references a block address from another function, and only the first function is lazily loaded. I fixed this the same way as PR11677: by eagerly loading the referenced function. - A function whose block address is taken is dematerialized, leaving invalid references to it. I fixed this by refusing to dematerialize functions whose block addresses are taken (if you have to load it, you can't unload it). llvm-svn: 214559
2014-08-01Try to fix configure+make after r214556Duncan P. N. Exon Smith1-1/+1
llvm-svn: 214558
2014-08-01Rewrite BitReaderTest, NFCDuncan P. N. Exon Smith2-32/+40
Rewrite the single unit test in `BitReaderTest` so that it's easier to add more tests. - Parse from an assembly string rather than using API. - Use more helper functions. - Use a separate context for the module on the other side. Aside from relying on the assembly parser, there's no functionality change intended. llvm-svn: 214556
2014-04-15verify-di: Implement DebugInfoVerifierDuncan P. N. Exon Smith1-0/+1
Implement DebugInfoVerifier, which steals verification relying on DebugInfoFinder from Verifier. - Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps DebugInfoVerifier. Uses -verify-di command-line flag. - Change verifyModule() to invoke DebugInfoVerifier as well as Verifier. - Add a call to createDebugInfoVerifierPass() wherever there was a call to createVerifierPass(). This implementation as a module pass should sidestep efficiency issues, allowing us to turn debug info verification back on. <rdar://problem/15500563> llvm-svn: 206300
2014-03-06Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles1-2/+2
This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-01-13Update getLazyBitcodeModule to use ErrorOr for error handling.Rafael Espindola1-2/+3
llvm-svn: 199125
2014-01-13[cleanup] Move the Dominators.h and Verifier.h headers into the IRChandler Carruth1-1/+1
directory. These passes are already defined in the IR library, and it doesn't make any sense to have the headers in Analysis. Long term, I think there is going to be a much better way to divide these matters. The dominators code should be fully separated into the abstract graph algorithm and have that put in Support where it becomes obvious that evn Clang's CFGBlock's can use it. Then the verifier can manually construct dominance information from the Support-driven interface while the Analysis library can provide a pass which both caches, reconstructs, and supports a nice update API. But those are very long term, and so I don't want to leave the really confusing structure until that day arrives. llvm-svn: 199082
2013-12-10[CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt.NAKAMURA Takumi1-0/+2
llvm-svn: 196908
2013-01-23llvm/unittests: Use OwningPtr to fix --vg-leak.NAKAMURA Takumi1-3/+3
llvm-svn: 173240
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-4/+4
into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2012-06-21llvm/unittests: Simplify LINK_COMPONENTS.NAKAMURA Takumi1-1/+1
llvm-svn: 158942
2012-06-21Completely refactor the structuring of unittest CMake files to match theChandler Carruth1-0/+8
Makefiles, the CMake files in every other part of the LLVM tree, and sanity. This should also restore the output tree structure of all the unit tests, sorry for breaking that, and thanks for letting me know. The fundamental change is to put a CMakeLists.txt file in the unittest directory, with a single test binary produced from it. This has several advantages: - No more weird directory stripping in the unittest macro, allowing it to be used more readily in other projects. - No more directory prefixes on all the source files. - Allows correct and precise use of LLVM's per-directory dependency system. - Allows use of the checking logic for source files that have not been added to the CMake build. This uncovered a file being skipped with CMake in LLVM and one in Clang's unit tests. - Makes Specifying conditional compilation or other custom logic for JIT tests easier. It did require adding the concept of an explicit 'optional' source file to the CMake build so that the missing-file check can skip cases where the file is *supposed* to be missing. =] This is another chunk of refactoring the CMake build in order to make it usable for other clients like CompilerRT / ASan / TSan. Note that this is interdependent with a Clang CMake change. llvm-svn: 158909
2012-02-29Bitcode: Don't expose WriteBitcodeToStream to clients.Daniel Dunbar1-6/+6
llvm-svn: 151747
2012-01-02Undo the hack in r147427 and move this unittest to a better home. ThisChandler Carruth2-0/+80
is testing the bitcode reader's functionality, not VMCore's. Add the what is a hope sufficient build system mojo to build and run a new unittest. Also clean up some of the test's naming. The goal for the file should be to unittest the Bitcode Reader, and this is just one particular test among potentially many in the future. Also, reverse my position and relegate the PR# to a comment, but stash the comment on the same line as the test name so it doesn't get lost. This makes the code more self-documenting hopefully w/o losing track of the PR number. llvm-svn: 147431