similar to: Will libFuzzer be part of future release binary packages?

Hi All, Currently libfuzzer depends on (often freshly built) clang, yet the dependency is not explicitly specified in cmake. That leads to various issues: for instance, it’s not possible to check out LLVM repo and run libfuzzer tests: one would often need to compile fresh clang first, and then create a separate build directory, where libfuzzer could be tested. For the buildbot this problem is

Hi all, While playing with libFuzzer, it's a little cumbersome to having to copy the buffer just in order to null-terminate it. Is a null-terminated buffer an often-enough usage scenario to warrant a libFuzzer commandline configuration switch to always generate a null-terminated test case? Thanks, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL:

With `save-temps` as plugin option, I get extra files for the MAIN module (called `a.o`): `a.o.opt.bc` and `a.thinlto.bc`. The `a.thinlto.bc` file contains nothing, only `source_filename = ...` . The `a.o.opt.bc` (this looks like the result after ThinLTO importing and optimization) contains the assembly block that it should not have: ``` module asm "\09.text" module asm

On Thu, Oct 31, 2019 at 3:46 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Oct 30, 2019 at 4:17 PM Johan Engelen <jbc.engelen at gmail.com> > wrote: > >> Hi all, >> Since 2724d9e12960cc1d93eeabbfc9aa1bffffa041cc, llvm-config -cxxflags >> no longer reports the C++ language standard version (e.g. "-std=c++14") >> used to

On Mon, Oct 3, 2016 at 4:27 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:53 AM, Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> I am trying to add ThinLTO to the LDC compiler. It seems to work well >> on Mac (XCode 8) and Ubuntu (ld.gold + LLVMgold plugin). >> However, I am

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in

Hi all, Since 2724d9e12960cc1d93eeabbfc9aa1bffffa041cc, llvm-config -cxxflags no longer reports the C++ language standard version (e.g. "-std=c++14") used to compile LLVM. This may break builds of projects that build with the same flags as LLVM, e.g. the LDC compiler. Quoting from llvm/tools/llvm-config/CMakeLists.txt: ``` # The language standard potentially affects the ABI/API of

The plugin version (and LLVM) are LLVM 3.9.0 (the release source tarball). I've attached the source files and the temporary files generated. `a.o` is the "MAIN" module. `b.o` is the "ASM" module. The error I get is: /usr/bin/ld: error: a.o.thinlto.o: multiple definition of 'foo' /usr/bin/ld: b.o.thinlto.o: previous definition here (the files depend on D runtime

Hello all, For CI testing of LDC with LLVM trunk we use CircleCI, which offers Ubuntu Trusty 14.04. We use apt.llvm.org, but the latest update of the "nightly" package is now more than a month ago. Previously the update rate was once a week, which was OK as it meant that we only had a few days of test breakage after an API change (and after a dev updated LDC to build with a locally

Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We

On Wed, Mar 9, 2016 at 10:30 PM, Sylvestre Ledru via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Le 09/03/2016 à 21:44, Yury V. Zaytsev a écrit : > > On Wed, 9 Mar 2016, Sylvestre Ledru wrote: > > > >> This is still maintained. However the cmake transition (for both 3.8 > >> and 3.9) wasn't simple... While it should be fine for debian, it >

On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com> > wrote: > > > > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the > > compiler has no support for always_inline (currently it is set to > nothing in > > that

Hi all, I am trying to add ThinLTO to the LDC compiler. It seems to work well on Mac (XCode 8) and Ubuntu (ld.gold + LLVMgold plugin). However, I am running into trouble with module-scope inline assembly blocks. I have a module ASM with a function `foo` defined in an inline assembly block (and an LLVM IR `declare @foo()` for it). There is also a "normal" function `void

Le 12/03/2016 à 14:15, Johan Engelen a écrit : > > > > I'm not sure how clean / dirty of a solution you'd be okay with, but > > I'd just point out that CMake developers provide working binary > > tarballs for Linux with every release at > https://cmake.org/download/ . > > So, if you are not a purist and/or need the CMake backport for

Hi all, I added support for the allocsize function attribute to our compiler (LDC), thinking that that would enable removal of function calls when the allocated memory is not used. For example: ``` declare i8* @my_malloc(i32) allocsize(0) define void @test_malloc() { %1 = call i8* @my_malloc(i32 100) ret void } ``` I thought the my_alloc call in test_malloc would be removed, but `opt -O3`

On Wed, Apr 13, 2016 at 2:09 AM, Amaury SECHET via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'd like to shime in here. These apt repository used to contain packages > named llvm-3.8-tools containing, amongst other things, the lit python > library used to test llvm. It seems that it went away recently and I have > travis build failing because of this. > > What is

On Sat, Jun 11, 2016 at 7:57 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 06/11/2016 07:52 PM, Johan Engelen via llvm-dev wrote: > > On Fri, Jun 10, 2016 at 9:00 PM, Sylvestre Ledru via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > http://llvm-apt.ecranbleu.org/apt/ > > > >

Hi all, I have a static library with object files with the same name (not the same full path, but the archive made with llvm-ar does not store the full path). The library contains object files that have been compiled with `-flto=thin` (compiled with LDC, not clang, but that shouldn't matter). When linking to that static library, I get the error: Assertion failed:

On Mon, Jun 20, 2016 at 10:01 AM, Anton Korobeynikov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > P.S.: On a similar note, are there any news regarding llvm.org/apt? > We are working on it. Note, however, that it seems that the majority > of bogus load seemed to come from CI systems, which pulled apt repo > for every and each downstream commit without any caching /

On Wed, Sep 6, 2017 at 1:10 PM, Johan Engelen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Sep 5, 2017 at 11:34 PM, Davide Italiano <dccitaliano at gmail.com> > wrote: >> >> On Tue, Sep 5, 2017 at 2:09 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> > >> > Hi Johan, >> > >> > Right, per the bug