similar to: Disabling LLVM_ATTRIBUTE_ALWAYS_INLINE for development?

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

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

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

I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)

Well, it looks like almost all of the problems go away when I build using trunk instead of 3.9. So, that was scary but I'm going to forget it ever happened. >8000 test cases failed under Valgrind!! John On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote: > Hi John, > > This is probably somewhat of a stretch, but since the problem does not > happen with a Debug build,

Thank you for the link and the suggestion to try master! I did so and discovered that it reproduces on master for me as well. The repro script I used (unchanged from before) and the output can be found here: https://gist.github.com/modocache/d9700166067f4a155820bc57d9bee1f3 (Note that the output looks nearly identical, but it's using clang-10 from the master branch of llvm-project.) I wonder

Vedant, Jeremy, Thanks a ton! I copied ASan's use of 'replaceDbgDeclare', think that worked! https://github.com/modocache/llvm-project/commit/afbc04e1dcba has some extremely quick and dirty changes I made (with no tests!), and a link to a Gist with the LLVM IR and DWARF produced, https://gist.github.com/modocache/6f29093ba2827946011b422ed3bd2903. There's only one kink: the spot

I haven't fully parsed this thread (sorry!), but I wanted to briefly mention that the SafeStack & ASan passes both do something similar (I think): move local variables backed by allocas onto a separate stack. These passes use replaceDbgDeclare to rewrite dbg.declares s.t. they point into the new stack. After that, llvm presumably runs LowerDbgDeclare (usually via InstCombine), but all the

Hi Brian, On Tue, Feb 25, 2020 at 7:43 PM Brian Gesiak <modocache at gmail.com> wrote: > In other words, the value of %i is stored on the frame object, on the > heap, at an offset of 7 into the frame. I'm beginning to think a > fundamental fix for this issue would be to stop replacing > llvm.dbg.declare with llvm.dbg.value, and instead replace the > llvm.dbg.declare with

On 11/18/19 10:45 AM, Martin Maechler wrote: >>>>>> Tomas Kalibera >>>>>> on Mon, 18 Nov 2019 09:36:14 +0100 writes: > > On 11/18/19 9:18 AM, Martin Maechler wrote: > >>>>>>> Henrik Bengtsson > >>>>>>> on Sun, 17 Nov 2019 14:31:07 -0800 writes: > >> > $ R --vanilla R

On 11/18/19 9:18 AM, Martin Maechler wrote: >>>>>> Henrik Bengtsson >>>>>> on Sun, 17 Nov 2019 14:31:07 -0800 writes: > > $ R --vanilla R version 3.6.1 (2019-07-05) -- "Action of > > the Toes" Copyright (C) 2019 The R Foundation for > > Statistical Computing Platform: x86_64-pc-linux-gnu > > (64-bit) ...

On Thu, Jan 10, 2019 at 1:20 PM Davide Italiano <davide at freebsd.org> wrote: > > On Wed, Jan 9, 2019 at 2:18 PM Davide Italiano <davide at freebsd.org> wrote: > > > > On Wed, Jan 9, 2019 at 9:38 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > > > > > > > > > On Fri, Jan 4, 2019 at 3:15 PM Davide Italiano via llvm-dev

There are two 64-bit bitmasks maintained in AttributeImpl.h<https://sdocc.itg.ti.com/ui#file:review=11893/version=393846>: - AvailableFunctionAttrs is part of the AttributeListImpl class, and - AvailableAttrs is part of the AttributeSetNode class Both of these assume that the number of available enum attributes is limited to 64. In fact, a static_assert in

Hi folks, Python2 has reached end of support[0], and many core Python packages are dropping pthon 2 support[1]. This is a subject that raises periodically on this mlist, with a rather strong no in 2018 [-1] and a slow move in 2019 [-2, -3]. Even if Python is not a core build requirement, it's used during some configurations steps (e.g. in the cmake export_executable_symbols function), for

I have been working for extending test coverage for years. Nowadays, I have several cross-testing (target != host). See http://bb.pgr.jp/console Each of them (test-*-linux) is doing; - Assume a preceding builder passes with warming ccache. - All compilation units will hit ccache whenever the tree is built before lit. - Almost all compilation units will hit ccache except for Host.cpp when

> On Wed, Jun 28, 2017 at 8:13 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > I don't object to adding some kind of filtering option, but in general it won't help. An important goal here is to provide analysis (and other) tools to users that present this information at a higher level. The users won't, and shouldn't, know exactly what kinds of messages the tools use.

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 Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com> wrote: > > On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Isn’t the problem the fact that the patch makes it harder for a target to >> get the generic code to reach its custom hook? >> Now the "cheap pow2 sdiv” is merged with the generic