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

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

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

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 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov> wrote: >> Creating constexpr StringRefs isn't trivial as strlen isn't portably >> constexpr and std::char_traits<char>::length is only constexpr in >> C++17. > > Why don't we just create our own traits class that has a constexpr length, and then we can switch over to the standard one when

On Fri, Nov 25, 2016 at 6:10 AM Mueller-Roemer, Johannes Sebastian via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What about going for > > template<unsigned N> > constexpr StringRef(const char (&Str)[N]) > > and avoiding strlen entirely for string literals? > You'd at least want an assert in there (that N - 1 == strlen(Str)) in case a StringRef is

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

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

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.

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

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

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

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

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

OK - good to know. (not sure we're talking about pessimizing it - just not adding a new/possible optimization, to be clear) Just out of curiosity - are there particular reasons you prefer or need to ship an MSVC built version, rather than a bootstrapped Clang? On Mon, Nov 28, 2016 at 9:24 AM Robinson, Paul <paul.robinson at sony.com> wrote: > So I wouldn't personally worry too

The fact that the templatized constructor falls down because of the possibility of initializing StringRef with a stack-allocated char array kills that idea in my mind. I feel like the only two reasonable solutions are 1) allow UDL for this case, document that this is an exception and that UDLs are still not permitted anywhere else, and require (by policy, since I don't know of a way to have