Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.0 2019-08-15T15:54:37+00:00 2019-08-15T15:54:37+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-08-15T15:54:37+00:00 urn:sha1:0eaee545eef49ff9498234d3a51a5cbde59bf976 Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013 2019-02-01T02:28:03+00:00 James Y Knight jyknight@google.com 2019-02-01T02:28:03+00:00 urn:sha1:13680223b9d80bb01e17372f0907cf215e424cce 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 2019-01-31T21:51:58+00:00 James Y Knight jyknight@google.com 2019-01-31T21:51:58+00:00 urn:sha1:fadf25068e32b44b010e6e03c6ab93bec41eae82 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 2019-01-31T20:35:56+00:00 James Y Knight jyknight@google.com 2019-01-31T20:35:56+00:00 urn:sha1:f47d6b38c7a61d50db4566b02719de05492dcef1 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 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 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 2017-04-11T15:01:18+00:00 Serge Guelton sguelton@quarkslab.com 2017-04-11T15:01:18+00:00 urn:sha1:59a2d7b9093617aff6b6f147ba267bc788aa08b7 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 2016-12-08T15:28:02+00:00 NAKAMURA Takumi geek4civic@gmail.com 2016-12-08T15:28:02+00:00 urn:sha1:689493bb124a4d02f6ba634a344cb0b6ba15cfd4 llvm-svn: 289060 2016-05-25T01:18:36+00:00 Eugene Zelenko eugene.zelenko@gmail.com 2016-05-25T01:18:36+00:00 urn:sha1:2b8e41705e26f2eba369037ef6f7ba83a47cdf4e Differential revision: http://reviews.llvm.org/D20607 llvm-svn: 270645 2016-01-26T21:29:08+00:00 Chris Bieneman beanz@apple.com 2016-01-26T21:29:08+00:00 urn:sha1:e49730d4baa8443ad56f59bd8066bf4c1e56ea72 Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861 2015-11-07T00:55:46+00:00 Duncan P. N. Exon Smith dexonsmith@apple.com 2015-11-07T00:55:46+00:00 urn:sha1:5717ecba8e7060b7e916d60f474aaead59b52798 llvm-svn: 252379