summaryrefslogtreecommitdiffstats
path: root/llvm/tools/bugpoint/Miscompilation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Bugpoint] fix another use-after-move. NFCNick Desaulniers2019-05-311-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No. 7". These statements are order independent, short of the use-after-move. Reviewers: echristo, srhines, RKSimon Reviewed By: RKSimon Subscribers: dblaikie, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62114 llvm-svn: 362267
* [Bugpoint] fix use-after-move. NFCNick Desaulniers2019-05-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No. 6". Note that author also states: "Note that the loop doesn't actually execute at all." This is not true, but the author can be forgiven; there's two distinct variables with very similar identifiers: MiscompiledFunctions MisCompFunctions Reviewers: echristo, srhines, RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62113 llvm-svn: 361279
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-1/+2
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-2/+2
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+2
| | | | | | | | | 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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [bugpoint] Fix crash when testing for miscompilation.Rafael Espindola2018-04-241-7/+10
| | | | | | | | | | | Method BugDriver::performFinalCleanups(...) would delete Module object it worked on, which was also deleted by its caller (e.g. TestCodeGenerator(...)). Changed the code to avoid double delete and make Module ownership slightly clearer. Patch by Andrzej Janik. llvm-svn: 330763
* Change the BugDriver to store the current module with std::unique_ptr.Rafael Espindola2018-02-141-45/+43
| | | | | | | | | While there, change a bunch of helper functions to take references to avoid adding calls to get(). This should conclude the bugpoint yak shaving. llvm-svn: 325177
* Use std::uniue_ptr. NFC.Rafael Espindola2018-02-141-4/+4
| | | | llvm-svn: 325176
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-12/+6
| | | | llvm-svn: 325174
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-6/+5
| | | | llvm-svn: 325173
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-9/+5
| | | | llvm-svn: 325164
* Pass a module reference to CloneModule.Rafael Espindola2018-02-141-12/+12
| | | | | | | It can never be null and most callers were already using references or std::unique_ptr. llvm-svn: 325160
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-1/+1
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* [Bugpoint] Use `unique_ptr` correctly.Bryant Wong2017-04-051-11/+12
| | | | | | | | | | Moving Modules into `testMergedProgram` is incorrect (and causes segmentation faults) since all callers expect to retain ownership. This is evidenced by the later calls to `unique_ptr<Module>::get` in the same function. Differential Revision: https://reviews.llvm.org/D31727 llvm-svn: 299596
* Retire bugpoint's -R. hack.Joerg Sonnenberger2016-10-011-6/+2
| | | | | | | | | It got disconnected during the cmake conversion. For Miscompilation.cpp, it was purely advisory for the user and the ToolRunner.cpp version was trying to compensate for libs and bins in the same directory, which hasn't been the case for a very long time. llvm-svn: 283022
* bugpoint: Return Errors instead of passing around stringsJustin Bogner2016-09-061-175/+195
| | | | | | | | | | | | | This replaces the threading of `std::string &Error` through all of these APIs with checked Error returns instead. There are very few places here that actually emit any errors right now, but threading the APIs through will allow us to replace a bunch of exit(1)'s that are scattered through this code with proper error handling. This is more or less NFC, but does move around where a couple of error messages are printed out. llvm-svn: 280720
* Revert "bugpoint: Stop threading errors through APIs that never fail"Justin Bogner2016-09-061-34/+33
| | | | | | | | | | | | | This isn't the right thing to do - it turns out a number of the APIs that "never fail" just exit(1) if something bad happens. We can and should thread Error through this instead. That diff will make more sense with this reverted. Sorry for the noise. This reverts r280690 llvm-svn: 280691
* bugpoint: Stop threading errors through APIs that never failJustin Bogner2016-09-061-33/+34
| | | | | | | | | | | | | This simplifies ListReducer and most of its subclasses by removing the std::string &Error that was threaded through all of them but almost never used. If we end up needing error handling in more places here we can reinstate it using llvm::Error instead of these unwieldy strings. The 2 cases (out of 12) that actually can hit the error cases are a little bit awkward now, but those will clean up as I refactor this API further. llvm-svn: 280690
* bugpoint: clang-format all of bugpoint. NFCJustin Bogner2016-09-021-207/+204
| | | | | | | I'm going to clean up the APIs here a bit and touch many many lines anyway. llvm-svn: 280450
* [bugpoint] Simplify code by moving exception to only callerPhilip Reames2016-06-291-2/+8
| | | | llvm-svn: 274083
* Fix Clang-tidy readability-redundant-control-flow warnings; other minor fixes.Eugene Zelenko2016-02-021-8/+5
| | | | | | Differential revision: http://reviews.llvm.org/D16793 llvm-svn: 259539
* Change linkInModule to take a std::unique_ptr.Rafael Espindola2015-12-161-4/+5
| | | | | | | Passing in a std::unique_ptr should help find errors when the module is used after being linked into another module. llvm-svn: 255842
* Use diagnostic handler in the LLVMContextRafael Espindola2015-12-141-15/+4
| | | | | | | | | | | | | | | | This patch converts code that has access to a LLVMContext to not take a diagnostic handler. This has a few advantages * It is easier to use a consistent diagnostic handler in a single program. * Less clutter since we are not passing a handler around. It does make it a bit awkward to implement some C APIs that return a diagnostic string. I will propose new versions of these APIs and deprecate the current ones. llvm-svn: 255571
* Simplify testMergedProgram.Rafael Espindola2015-12-091-26/+19
| | | | | | It now receives and returns std::unique_ptr. llvm-svn: 255087
* Simplify memory management. NFC.Rafael Espindola2015-12-091-79/+72
| | | | | | | This passes std::unique_ptr to predicates that are expected to delete their argument. llvm-svn: 255086
* Return std::unique_ptr from SplitFunctionsOutOfModule. NFC.Rafael Espindola2015-12-091-14/+14
| | | | llvm-svn: 255084
* Simplify memory management. NFC.Rafael Espindola2015-12-091-11/+10
| | | | llvm-svn: 255082
* Simplify memory management a bit. NFC.Rafael Espindola2015-12-091-9/+8
| | | | llvm-svn: 255079
* Return a std::unique_ptr from CloneModule. NFC.Rafael Espindola2015-12-081-12/+12
| | | | llvm-svn: 255078
* Always pass a diagnostic handler to the linker.Rafael Espindola2015-12-041-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Before this patch the diagnostic handler was optional. If it was not passed, the one in the LLVMContext was used. That is probably not a pattern we want to follow. If each area has an optional callback, there is a sea of callbacks and it is hard to follow which one is called. Doing this also found cases where the callback is a nice addition, like testing that no errors or warnings are reported. The other option is to always use the diagnostic handler in the LLVMContext. That has a few problems * To implement the C API we would have to set the diag handler and then set it back to the original value. * Code that creates the context might be far away from code that wants the diagnostics. I do have a patch that implements the second option and will send that as an RFC. llvm-svn: 254777
* Use references now that it is natural to do so.Rafael Espindola2015-12-011-4/+4
| | | | | | | The linker never takes ownership of a module or changes which module it is refering to, making it natural to use references. llvm-svn: 254449
* bugpoint: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-201-10/+8
| | | | | | | | This is the last of the implicit ilist iterator conversions in LLVM. Still up for debate whether we let these bitrot back: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091617.html llvm-svn: 250852
* [Bugpoint] Use 'CC' instead of 'GCC' for variable naming.Davide Italiano2015-10-141-2/+2
| | | | | | | | | | We now use clang by default and fallback to gcc when requested. With this commit, names reflect reality. No functional change intended. Discussed with: Rafael Espindola. llvm-svn: 250321
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-8/+4
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-1/+2
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* Teach raw_ostream to accept SmallString.Yaron Keren2015-03-101-7/+7
| | | | | | | | | | | | | | Saves adding .str() call to any raw_ostream << SmallString usage and a small step towards making .str() consistent in the ADTs by removing one of the SmallString::str() use cases, discussion at http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141013/240026.html I'll update the Phabricator patch http://reviews.llvm.org/D6372 for review of the Twine SmallString support, it's more complex than this one. llvm-svn: 231763
* Remove the PreserveSource linker mode.Rafael Espindola2014-10-281-6/+4
| | | | | | | | | | | | | | | | | | | | I noticed that it was untested, and forcing it on caused some tests to fail: LLVM :: Linker/metadata-a.ll LLVM :: Linker/prefixdata.ll LLVM :: Linker/type-unique-odr-a.ll LLVM :: Linker/type-unique-simple-a.ll LLVM :: Linker/type-unique-simple2-a.ll LLVM :: Linker/type-unique-simple2.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/unnamed-addr1-a.ll LLVM :: Linker/visibility1.ll If it is to be resurrected, it has to be fixed and we should probably have a -preserve-source command line option in llvm-mc and run tests with and without it. llvm-svn: 220741
* Update the error handling of lib/Linker.Rafael Espindola2014-10-251-23/+7
| | | | | | Instead of passing a std::string&, use the new diagnostic infrastructure. llvm-svn: 220608
* Return a std::unique_ptr from parseInputFile and propagate. NFC.Rafael Espindola2014-08-261-15/+16
| | | | | | | | The memory management in BugPoint is fairly convoluted, so this just unwraps one layer by changing the return type of functions that always return owned Modules. llvm-svn: 216464
* Remove 'using std::error_code' from tools.Rafael Espindola2014-06-131-5/+4
| | | | llvm-svn: 210876
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-0/+1
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* [C++] Use 'nullptr'. Tools edition.Craig Topper2014-04-251-3/+3
| | | | llvm-svn: 207176
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-9/+9
| | | | | | class. llvm-svn: 203345
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-3/+4
| | | | | | | | | | 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
* [Layering] Sink Linker.h into a Linker subdirectory to make itChandler Carruth2014-03-061-1/+1
| | | | | | consistent with every other sub-library header in LLVM. llvm-svn: 203065
* [C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles2014-03-051-2/+2
| | | | llvm-svn: 202957
* [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
OpenPOWER on IntegriCloud