similar to: llvm-config --cxxflags should report C++ language standard version

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

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 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

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

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 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, 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

It is expected and not unusual to need to update the lit test in such case. I'd need to see exactly which test breaks and how to know though. Best, -- Mehdi 2017-09-18 13:17 GMT-07:00 Johan Engelen <jbc.engelen at gmail.com>: > The fix (https://reviews.llvm.org/D37961) does not work. From what I > have learned thusfar, the module identifier is used as filename sometimes >

I've created a review for your patch Mehdi: https://reviews.llvm.org/D37961 First time using `arc`, so hope things went well. - Johan On Tue, Sep 12, 2017 at 5:25 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi Johan, > > 2017-09-11 14:21 GMT-07:00 Johan Engelen <jbc.engelen at gmail.com>: > >> On Fri, Sep 8, 2017 at 9:04 PM, Johan Engelen

The fix (https://reviews.llvm.org/D37961) does not work. From what I have learned thusfar, the module identifier is used as filename sometimes (I think when writing an intermediate module index summary), and so a bunch of lit tests fail with the "fix". I'll look further into fixing this, any help is appreciated. ( One thing that may be important is to have a deterministic suffix.

On Fri, Sep 8, 2017 at 9:04 PM, Johan Engelen <jbc.engelen at gmail.com> wrote: > > On Thu, Sep 7, 2017 at 5:44 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > >> Hi Johan, >> >> ld64 only calls functions from llvm/include/llvm-c/lto.h (defined >> in llvm/tools/lto/lto.cpp) >> >> For instance ThinLTOCodeGenerator::addModule is called

On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org>: > > The error is gone after removing (or reducing) the alignment of `%a`. > This > > makes me believe that our inline asm syntax is correct to add an offset > to a > > pointer: "

Is there any eta for when viewvc will be back? I prefer to use viewvc because all of the commit emails have the SVN commit number, but not the corresponding git hashes, so it makes it easier to look it up. Or is there some easy way to map an svn commit number to the corresponding git hash? Douglas Yung From: Johan Engelen [mailto:jbc.engelen at gmail.com] Sent: Saturday, March 12, 2016 5:03 AM

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

It's currently disabled until the issues with llvm.org load would be resolved. Use klaus instead. On Sat, Feb 27, 2016 at 6:53 AM, Yung, Douglas via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I’ve noticed since about Thursday that llvm.org/viewvc seems to be only > returning 404 error when trying to access it. Is this service going away? > > >

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 >

Hi all, Will libFuzzer be part of the release pre-built binaries at http://releases.llvm.org/ in the future? Thanks, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/91c6cffe/attachment.html>

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

On Sun, Dec 20, 2015 at 5:24 PM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: > LLVM_ATTRIBUTE_ALWAYS_INLINE is defined to be __forceinline for MSVC. I > wonder why you get that warning. inline and __forceinline don't mix with MSVC -- I believe they may be modeled with the same attribute under the hood. I'm not certain of the best way to solve this aside

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