similar to: [RFC] improvements to LLVM diagnostic infrastructure

Hi all, I'm trying to compile chrome using clang 8, apart from changing few switches I didn't go that far. In particular the error is due to a missing plugin: find-bad-constructs. With clang 6 I didn't have that specific problem. Can anyone help with this? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 9/7/2012 12:12 PM, Krzysztof Parzyszek wrote: > On 9/7/2012 7:20 AM, Matthew Curtis wrote: >> >> The attached patch implements one possible solution. It introduces a >> position stack and a couple of directives: >> >> * 'CHECK-PUSH:' pushes the current match position onto the stack. >> * 'CHECK-POP:' pops the top value off of the stack

[apologies for this duplicate post: originally sent to lldb-dev by not paying attention to the address auto-completion] We have a backend for a target that at present only detects some assembler errors when emitting instructions (basically because the platform has configurable properties with dependencies between instructions and it was easier to check for their interaction late than try to

On 9/7/2012 7:20 AM, Matthew Curtis wrote: > > The attached patch implements one possible solution. It introduces a > position stack and a couple of directives: > > * 'CHECK-PUSH:' pushes the current match position onto the stack. > * 'CHECK-POP:' pops the top value off of the stack and uses it to set > the current match position. > > The above

Hello all, For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested. For example: ; CHECK: memw(##a) ; CHECK: memw(##b) %0 = load i32* @a, align 4 %1 = load i32* @b, align 4 requires that the compiler emit the memory operations for

Tried that just now, same result. On Fri, Mar 25, 2016 at 6:58 AM, Snehasish Kumar <kumar.snehasish at gmail.com> wrote: > Hi Russel, > > Can you try compiling aklo.o using -fno-rtti prior to linking? > > On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm trying to link a program with LLVM on Linux.

I'm trying to link a program with LLVM on Linux. I've managed to take out the test files from 'llvm-config --libs' but now it's getting errors with missing symbols. The same program successfully links with the same version of LLVM (3.8) on Windows, so it's not a problem with the code per se, it's some kind of configuration issue. Any ideas? g++ -std=c++11

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

Hi Russel, Can you try compiling aklo.o using -fno-rtti prior to linking? On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm trying to link a program with LLVM on Linux. I've managed to take out > the test files from 'llvm-config --libs' but now it's getting errors with > missing symbols. The same program

I've tried using SourceMgr in a parser to get the nice error reporting with automatic line/column tracking, and it works well. I'm thinking about extending that to try to get the nice error reporting in subsequent type checking, and that leads to a question. As I understand it, SourceMgr owns the memory buffers (be they allocated chunks of memory, or memory mapped files) containing the

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object

Hmm. What about the errors I quoted from using clang-7 (starting about a third of the way down my email, sorry if they got kinda lost in all the noise)? Thanks, Jay. On Tue, 3 Sep 2019 at 20:00, David Blaikie <dblaikie at gmail.com> wrote: > > Looks to me like a bug in GCC's constexpr+_GLIBCXX_CONCEPT_CHECKS support. Small test case: > > $ g++-8 test.cpp -std=c++2a

I just ran into this today. Do we need to update our requirements on libstdc++ version? Jay, did you figure out a way around this? On Wed, Sep 4, 2019 at 5:29 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It's a bug in libstdc++ - so if you have clang using libstdc++ (which it will by default, I think) then it's the same thing. You could try with

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Hello, I have been playing with the XCP for a while now, and must say I''m very exited about the technology. I had no prior experience with Xen so it has taken me a while to understand the concepts, but now I feel most important issues are solved and I''ve purchased some hardware to build my (tiny) cloud on. The box is a Supermicro 1026TT-IBXF, so I have 2 x Ethernet and 1 x

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

SourceMgr provides AddIncludeFile which I'm thinking of using for parsing the TPTP language. As far as I can see, AddIncludeFile only deals with #include <...> style, i.e. only search the include directories. I don't see any code for dealing with #include "...", i.e. first look relative to the current file. Is there something I'm missing? How does clang handle this?

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

Hello, There is an issue in the latest Sparc code: while we can encode POPC, decode results in crash in llvm-mc $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble -triple=sparcv9 -show-encoding .text popc %g1, %g2 ! encoding: [0x85,0x70,0x00,0x01] $ echo "0x85,0x70,0x00,0x01"|./Release+Asserts/bin/llvm-mc -disassemble -triple=sparcv9

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to