similar to: MSVC warning noise on "LLVM_ATTRIBUTE_ALWAYS_INLINE inline void foo()"

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

Hi all, Some functions have "inline" specified twice by use of LLVM_ATTRIBUTE_ALWAYS_INLINE. For example in StringRef.h: LLVM_ATTRIBUTE_ALWAYS_INLINE inline bool operator==(StringRef LHS, StringRef RHS); This results in warning noise when compiled with MSVC 2015: \include\llvm/ADT/StringRef.h(567): warning C4141: 'inline': used more than once

Hello all! I find that using lldb to debug LLVM libraries can be super frustrating, because a lot of LLVM classes, like the constructor for StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt to have lldb evaluate an expression that implicitly instantiates a StringRef, I get 'error: Couldn't lookup symbols: __ZN4llvm9StringRefC1EPKc'. As an example, most recently

On Sat, Dec 15, 2018 at 12:02 PM Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > > On Dec 15, 2018, at 10:32 AM, Brian Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hello all! > > > > I find that using lldb to debug LLVM libraries can be super > > frustrating, because a lot of LLVM classes, like

On Sat, Dec 15, 2018 at 9:37 PM Chandler Carruth <chandlerc at gmail.com> wrote: > > On Sat, Dec 15, 2018 at 6:13 PM Davide Italiano <davide at freebsd.org> wrote: >> >> On Sat, Dec 15, 2018 at 12:02 PM Vedant Kumar via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > Hi, >> > >> > > On Dec 15, 2018, at 10:32

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.

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

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

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

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

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

We should handle this a lot better after r34763 ~Craig On Mon, Nov 26, 2018 at 3:13 PM Craig Topper <craig.topper at gmail.com> wrote: > Here's a quick patch that fixes this. I don't know to avoid it in IR. I > haven't checked any other tests, but it does fix your case. I'll try to put > up a real phabricator tonight or tomorrow. > > diff --git

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