similar to: llvm-9-dev apt package missing yaml-bench

On 02/12/2019 15:21, Sylvestre Ledru wrote: > yaml-bench is shipping in libclang-common-9-dev Ok possible. Though, it adds an unnecessary 46MB to my docker image. > It should be indeed in llvm-9-dev instead. This would hide the problem, right. I am not sure it's is a good solution. Where can we review the build process for the apt packages? On 02/12/2019 15:21, Sylvestre Ledru wrote:

On Mon, May 9, 2016 at 4:46 PM Sylvestre Ledru <sylvestre at debian.org> wrote: > Le 09/05/2016 à 07:34, Paweł Bylica a écrit : > > llvm-3.8-dev is broken: > > > > CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include): > > include could not find load file: > > > > /usr/share/llvm/cmake/LLVMExports.cmake > Brad King helped me

Le 09/05/2016 à 16:59, Paweł Bylica a écrit : > On Mon, May 9, 2016 at 4:46 PM Sylvestre Ledru <sylvestre at debian.org > <mailto:sylvestre at debian.org>> wrote: > > Le 09/05/2016 à 07:34, Paweł Bylica a écrit : > > llvm-3.8-dev is broken: > > > > CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 > (include): >

llvm-3.8-dev is broken: CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include): include could not find load file: /usr/share/llvm/cmake/LLVMExports.cmake llvm-3.7-dev is ok. Why is it so error prone for so many years? On Sun, May 8, 2016 at 11:31 PM Amaury SECHET via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, it turns out that the secret sauce to

On 6 July 2015 at 10:34, Ben Pope <benpope81 at gmail.com> wrote: > On 7 July 2015 at 01:12, Dan Liew <dan at su-root.co.uk> wrote: >> >> >> @Ben Pope: Your uploaded binary tarball is the odd one out. Any idea >> as to why the CMake files are missing and why the root directory name >> inside the tarball is not consistent with the uploaded tarballs for

Hi, I can't reproduce your issue on the LLVM 3.5 release branch or trunk it. Looking at your bug report I think your install is messed up ``` CMake Error at /usr/local/Cellar/llvm/HEAD/share/llvm/cmake/LLVMExports.cmake:6 (set_property): set_property could not find TARGET LLVMSupport. Perhaps it has not yet been created. Call Stack (most recent call first):

On 06/18/2015 06:46 PM, Dan Liew wrote: >> The issue is the that that generated LLVMExports.cmake file has this in it >> INTERFACE_LINK_LIBRARIES "LLVMObject;LLVMSupport;C:\Program Files (x86)\Microsoft Visual Studio 14.0\DIA SDK\lib\diaguids.lib" > > Hmm actually this might be a bug in the > ``/lib/DebugInfo/PDB/CMakeLists.txt`` file. CC'ing Zach Turner seeing

Hi, Following on from another thread (Long-Term Support for LLVM Projects Extension to Build System) I'd like to discuss the testing of the exported LLVM CMake targets which can be used by consumers of LLVM as documented in [1]. Right now we don't test this feature **at all** and as a result it has been or is * broken in trunk * broken by those packaging LLVM * broken in the official

Hi, Myself and a colleague of mine are trying to use LLVM's exported targets [1] on trunk and I've noticed that the generated CMake files (LLVMConfig.cmake and LLVMExport.cmake) are broken when trying to use Visual Studio 2015 (using CMake 3.2.1). ## Broken target properties in LLVMExports.cmake LLVM itself builds fine but when our project tries to do ``find_package(LLVM)`` we get the

Hi Ben, Thanks for taking the time to look at this. >> It's not necessary for CMake to be installed when building with the >> Autoconf/Makefile build system. If you look in the build directory >> after a build has been performed you should see in cmake/modules >> >> ``` >> LLVMBuildExports.cmake LLVMConfig.cmake LLVMConfigVersion.cmake >>

Hi, On Sun, Jan 17, 2016 at 1:04 PM, Dan Liew <dan at su-root.co.uk> wrote: > On 16 January 2016 at 20:21, Ismail Donmez <ismail at i10z.com> wrote: >> On Sat, Jan 16, 2016 at 9:33 PM, Dan Liew <dan at su-root.co.uk> wrote: >>>> I am trying to enable this on openSUSE but it seems to break >>>> standalone lldb (note that we don't ship static

Hi All, I am implementing E-pathPRE in LLVM. The coding part is almost complete and till now it worked fine on my test examples. But, I need to test with some standard bench-marks. Can anyone give me any information about standard bench-marks? or any other standard for testing my pass. Any help on this regards will be appreciated. Thank you and regards, Chayan Sarkar

On Sun, 1 May 2016 at 16:12 Amaury SECHET <deadalnix at gmail.com> wrote: > Some update on this. > > 2016-04-12 18:48 GMT-07:00 Andrew Wilkins <axwalk at gmail.com>: > >> On Wed, 13 Apr 2016 at 09:38 Amaury SECHET <deadalnix at gmail.com> wrote: >> >>> I'd be happy to do it, but this is a bit much high level for me to be >>>

Hi Björn I made a workaround for this specific issue a long time ago for the Projucer C++ JIT Engine. It basically forwards the call to another stub that provides enough space to encode a full 64-bit address. The patch is based on LLVM 3.9, so I guess it won't work out-of-the-box on a recent release, but it may give you enough hints to figure it out on your own:

Yes definitely, testing a small piece of code like the GlobPattern::create() example, it would mostly indicate missing unit tests or insufficient test data. In contrast to unit tests, however, it can also verify correct handling of errors passed between function call hierarchies in more complex scenarios. For this I should point to the other example in the code, where it's applied to

On 09/09/2014 10:12 AM, Dan Liew wrote: > because my Linux distribution just upgraded to LLVM/Clang 3.5 and I > noticed that trying use find_package(LLVM ...) was broken :( AFAIK, that never worked in any version of LLVM not built by CMake before. That's why we taught cmake/modules/Makefile to generate LLVMConfig.cmake and LLVMExports.cmake. > What is happening is that none of the

On Mon, Jul 31, 2017 at 8:19 AM Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > Hi Lang, hi David, thanks for looking into this. > > > > Did you identify many cases where "real work" (in your example, the > nullptr dereference" was being done in an error branch? > > In my own code yes, not in LLVM ;) I'd like to run it on a large example,

Hi again, On Fri, Jan 15, 2016 at 11:05 AM, Ismail Donmez <ismail at i10z.com> wrote: > Hi, > > On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com> wrote: >> I’m kinda scared that you’re using it. What are you trying to accomplish >> that you are using it? Generally having LLVM split among that many >> dynamically loaded libraries results

Hello, this is a call for feedback: opinions, improvements, testers.. I use the support classes Expected<T> and ErrorOr<T> quite often recently and I like the concept a lot! Thanks Lang btw! However, from time to time I found issues in the execution paths of my error cases and got annoyed by their naturally low test coverage. So I started sketching a test that runs all error paths

Hi Stefan, David, This is very interesting stuff - it adds a dimension of error security that Error/Expected can't provide on their own. I think it would be interesting to try to build a tool around this. Did you identify many cases where "real work" (in your example, the nullptr dereference" was being done in an error branch? My suspicion is that that should be rare, but that