summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/IR/VerifierTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Resolve an error at freeze's unit testsJuneyoung Lee2019-11-121-1/+1
|
* [IR] Redefine Freeze instructionaqjune2019-11-121-0/+48
| | | | | | | | | | | | | | | | | | | | Summary: This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction. ConstantExpr freeze is removed, as discussed in the previous review. FreezeOperator is not added because there's no ConstantExpr freeze. `freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed. InstVisitor has visitFreeze now because freeze is not unaryop anymore. Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri Reviewed By: craig.topper, lebedev.ri Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69932
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-7/+7
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [DebugInfo] DISubprogram flags get their own flags word. NFC.Paul Robinson2018-11-191-3/+4
| | | | | | | | | | | | | This will hold flags specific to subprograms. In the future we could potentially free up scarce bits in DIFlags by moving subprogram-specific flags from there to the new flags word. This patch does not change IR/bitcode formats, that will be done in a follow-up. Differential Revision: https://reviews.llvm.org/D54597 llvm-svn: 347239
* Move the stripping of invalid debug info from the Verifier to AutoUpgrade.Adrian Prantl2017-10-021-37/+1
| | | | | | | | | | | | | | | | | | | | | | | | This came out of a recent discussion on llvm-dev (https://reviews.llvm.org/D38042). Currently the Verifier will strip the debug info metadata from a module if it finds the dbeug info to be malformed. This feature is very valuable since it allows us to improve the Verifier by making it stricter without breaking bcompatibility, but arguable the Verifier pass should not be modifying the IR. This patch moves the stripping of broken debug info into AutoUpgrade (UpgradeDebugInfo to be precise), which is a much better location for this since the stripping of malformed (i.e., produced by older, buggy versions of Clang) is a (harsh) form of AutoUpgrade. This change is mostly NFC in nature, the one big difference is the behavior when LLVM module passes are introducing malformed debug info. Prior to this patch, a NoAsserts build would have printed a warning and stripped the debug info, after this patch the Verifier will report a fatal error. I believe this behavior is actually more desirable anyway. Differential Revision: https://reviews.llvm.org/D38184 llvm-svn: 314699
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* [DebugInfo] Changed DIBuilder::createCompileUnit() to take DIFile instead of ↵Amjad Aboud2016-12-141-4/+5
| | | | | | | | | | | | FileName and Directory. This way it will be easier to expand DIFile (e.g., to contain checksum) without the need to modify the createCompileUnit() API. Reviewers: llvm-commits, rnk Differential Revision: https://reviews.llvm.org/D27762 llvm-svn: 289702
* [unittests] Remove an MSVC 2013 workaround, NFCI.Vedant Kumar2016-10-251-3/+0
| | | | | | Let's see what the bots have to say about this... llvm-svn: 285090
* Verifier: Mark orphaned DICompileUnits as a debug info failure.Adrian Prantl2016-09-141-20/+53
| | | | | | | | | This is a follow-up to r268778 that adds a couple of missing cases, most notably orphaned compile units. rdar://problem/28193346 llvm-svn: 281508
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-25/+0
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* Port the strip-invalid-debuginfo logic to the legacy verifier pass, too.Adrian Prantl2016-05-251-1/+23
| | | | | | | | | | | | | | | | | | | | | Since r268966 the modern Verifier pass defaults to stripping invalid debug info in nonasserts builds. This patch ports this behavior back to the legacy Verifier pass as well. The primary motivation is that the clang frontend accepts bitcode files as input but is still using the legacy pass pipeline. Background: The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D20629 <rdar://problem/26448800> llvm-svn: 270768
* Delete duplicated verifier test.Rafael Espindola2016-05-111-0/+27
| | | | | | Also add unittest to show we still detect the errors. llvm-svn: 269182
* Disable this unit test on MSVC, which crashes while compiling it.Adrian Prantl2016-05-091-1/+3
| | | | llvm-svn: 268985
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 This reapplies r268937 without modifications. llvm-svn: 268966
* Revert "Separate the Verifier into an analysis and a transformation pass and"Adrian Prantl2016-05-091-25/+0
| | | | | | This reverts commit 268937 while investigating build bot breakage. llvm-svn: 268939
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-0/+25
| | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 llvm-svn: 268937
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-141-4/+4
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; ↵Eugene Zelenko2016-01-261-4/+5
| | | | | | | | other minor fixes. Differential revision: reviews.llvm.org/D16568 llvm-svn: 258831
* [Verifier] Check parentage of GVs in dbg metadataKeno Fischer2016-01-141-1/+23
| | | | | | | | | | | | | | | Summary: Before this the Verifier didn't complain if the GlobalVariable referenced from a DIGlobalVariable was not in fact in the correct module (it would crash while writing bitcode though). Fix this by always checking parantage of GlobalValues while walking constant expressions and changing the DIGlobalVariable visitor to also visit the constant it contains. Reviewers: rafael Differential Revision: http://reviews.llvm.org/D16059 llvm-svn: 257825
* [Verifier] Verify that a GlobalValue is only used in this ModuleKeno Fischer2016-01-141-2/+16
| | | | | | | | | | | | | Summary: We already have the inverse verification that we only use globals that are defined in this module. This essentially catches the same mistake, but when verifying the module that contains the definition. Reviewers: rafael Differential Revision: http://reviews.llvm.org/D15272 llvm-svn: 257823
* [Verifier] Improve error for cross-module refsKeno Fischer2015-12-011-0/+47
| | | | | | | | | | | | | | By including the module name in the error message. This makes the error message much more useful and saves a trip to the debugger. Reviewers: dexonsmith Subscribers: dexonsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D14473 llvm-svn: 254437
* Allow aliases to be unnamed_addr.Rafael Espindola2014-06-061-17/+0
| | | | | | | | | | | | | | | | | | Alias with unnamed_addr were in a strange state. It is stored in GlobalValue, the language reference talks about "unnamed_addr aliases" but the verifier was rejecting them. It seems natural to allow unnamed_addr in aliases: * It is a property of how it is accessed, not of the data itself. * It is perfectly possible to write code that depends on the address of an alias. This patch then makes unname_addr legal for aliases. One side effect is that the syntax changes for a corner case: In globals, unnamed_addr is now printed before the address space. llvm-svn: 210302
* Use create methods since msvc doesn't handle delegating constructors.Rafael Espindola2014-05-171-1/+1
| | | | llvm-svn: 209076
* Reduce abuse of default values in the GlobalAlias constructor.Rafael Espindola2014-05-171-2/+1
| | | | | | This is in preparation for adding an optional offset. llvm-svn: 209073
* Change the GlobalAlias constructor to look a bit more like GlobalVariable.Rafael Espindola2014-05-161-3/+2
| | | | | | | This is part of the fix for pr10367. A GlobalAlias always has a pointer type, so just have the constructor build the type. llvm-svn: 208983
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+0
| | | | | | | | | | 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
* [PM] Make the verifier work independently of any pass manager.Chandler Carruth2014-01-191-6/+9
| | | | | | | | | | | | | | | | | | | | | | | This makes the 'verifyFunction' and 'verifyModule' functions totally independent operations on the LLVM IR. It also cleans up their API a bit by lifting the abort behavior into their clients and just using an optional raw_ostream parameter to control printing. The implementation of the verifier is now just an InstVisitor with no multiple inheritance. It also is significantly more const-correct, and hides the const violations internally. The two layers that force us to break const correctness are building a DomTree and dispatching through the InstVisitor. A new VerifierPass is used to implement the legacy pass manager interface in terms of the other pieces. The error messages produced may be slightly different now, and we may have slightly different short circuiting behavior with different usage models of the verifier, but generally everything works equivalently and this unblocks wiring the verifier up to the new pass manager. llvm-svn: 199569
* [cleanup] Move the Dominators.h and Verifier.h headers into the IRChandler Carruth2014-01-131-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
* Add calls to doInitialization() and doFinalization() in verifyFunction()Rafael Espindola2013-10-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | The function verifyFunction() in lib/IR/Verifier.cpp misses some calls. It creates a temporary FunctionPassManager that will run a single Verifier pass. Unfortunately, FunctionPassManager is no PassManager and does not call doInitialization() and doFinalization() by itself. Verifier does important tasks in doInitialization() such as collecting type information used to check DebugInfo metadata and doFinalization() does some additional checks. Therefore these checks were missed and debug info couldn't be verified at all, it just crashed if the function had some. verifyFunction() is currently not used in llvm unless -debug option is enabled, and in unittests/IR/VerifierTest.cpp VerifierTest had to be changed to create the function in a module from which the type debug info can be collected. Patch by Michael Kruse. llvm-svn: 193719
* Add unit test to test a trivial verifier check.Bill Wendling2013-06-191-0/+16
| | | | llvm-svn: 184338
* Rename the VMCore unittest tree to IR. Somehow was missed when doing theChandler Carruth2013-01-071-0/+64
library rename. llvm-svn: 171747
OpenPOWER on IntegriCloud