similar to: [LLVMdev] Compiler error when self-hosting

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Compiler error when self-hosting"

2019 Sep 03
2
SourceMgr vs EXPENSIVE_CHECKS
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
2019 Sep 03
2
SourceMgr vs EXPENSIVE_CHECKS
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
2019 Oct 02
2
SourceMgr vs EXPENSIVE_CHECKS
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
2010 Sep 26
0
[LLVMdev] What is the canonical way to build on Solaris 10?
Hi, I am trying to get r114797 to build on Solaris 10u6 (5.10 Generic_142901-03). gcc 4.2 is installed and configured with: -bash-3.00$ /opt/gcc4/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ./configure --prefix=/opt/gcc4 --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++ Thread model:
2012 Jan 13
2
[LLVMdev] Memory leaks in LLVM on linux
I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()
2010 Oct 22
0
[LLVMdev] Crash with llc and vector code
Hi, Compiling the simple following function with llv (LLVM 2.8) : define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) { %res = select <4 x i1> <i1 true, i1 false, i1 true, i1 true>, <4 x i32> %a, <4 x i32> %b ; ret <4 x i32> %res } gives : UNREACHABLE executed! 0 llc 0x0000000100927422 std::_Rb_tree<llvm::sys::Path,
2010 Oct 22
1
[LLVMdev] Crash with llc and vector code
Hi, Compiling the simple following function with llv (LLVM 2.8) : define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) { %res = select <4 x i1> <i1 true, i1 false, i1 true, i1 true>, <4 x i32> %a, <4 x i32> %b ; ret <4 x i32> %res } gives : UNREACHABLE executed! 0 llc 0x0000000100927422 std::_Rb_tree<llvm::sys::Path,
2013 Mar 28
0
[LLVMdev] Avoid Valgrind's still-reachable leak warnings
Hi, I'm Ryo Onodera. This is my first post to this mailing list. Fist, thanks for creating a great library! We're using LLVM to support JIT in Rubinius (an alternative implementation of Ruby, a dynamic programming language). I'm submitting a small patch for a minor issue. It solves still-reachable leak warnings from Valgrind. Example warnings are shown at the end of this mail. As
2012 Dec 23
0
[LLVMdev] Alternative to llvm::TrackingVH
Hi all, I'm currently using llvm::TrackingVH in order to have a tracking reference to a definition. Unfortunately, TrackingVHs are incredibly slow. Are there alternatives? -- Roland
2017 Jan 25
2
LLVM 3.9.1 build race?
Hi Folks, I am building LLVM 3.9.1 using the Yocto build system for a cross build. The compiled bins/libs work totally fine on the target machine however there seems to be an intermittent race condition during the build which causes a build failure. On the failed builds I usually see things being linking/compiling twice e.g. Linking CXX static library ../libLLVMSupport.a cd
2006 Mar 20
1
type in daisy
Hi, I'm a PhD student and I want to use the function 'daisy' from the package 'cluster' to compute dissimilarities. My variables are of mixed types so I use the argument 'stand' in daisy to define the type of my variables. I have the following error message : Warning message: binary variable(s) 13, 16, 17, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,
2018 Jul 25
2
are the LLD libraries thread safe?
E.g. Is it intended to be allowed to call lld::elf::link in 2 different threads at the same time? Follows is an example Valgrind error I ran into when doing the above. I'll try putting a global resource lock on invoking LLD and see if it solves the problem. ==5467== Invalid write of size 8 ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int,
2018 Jul 25
2
are the LLD libraries thread safe?
Hi Andrew, LLD relies on various bits of global state which are manipulated during the link, so I wouldn't expect it to be thread safe at that level, although it does attempt to reset that global state at the start of each call to link(), so it should be callable sequentially. Regards, James On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:
2017 Apr 10
2
clang build failures using Visual Studio
Anyone run into this before? I'm trying to get a Windows native build using Visual Studio of LLVM, Clang, and LLD 4.0.0. So far LLVM built successfully, but I'm getting these cryptic error messages when building Clang: Microsoft (R) Build Engine version 15.1.1012.6693 Copyright (C) Microsoft Corporation. All rights reserved. ClangDiagnosticsEmitter.cpp c:\program files
2009 Apr 01
1
[LLVMdev] Patches: Range insertion for DenseSet; definition of DenseMapInfo<char>
Here are two minor patches. The first adds an insert method to DenseSet that takes two iterators representing the beginning and ending of a range of items to insert. I lifted the code verbatim from DenseMap.h. The second patch defines DenseMapInfo for chars. This is useful because DenseSet is implemented as a DenseMap of (Type, char), so anyone who uses DenseSet has to define DenseMapInfo for
2018 Jan 16
0
Running Scalar Evolution on Modules on an ad-hoc basis
Hello! I am attempting to write a program which can analyze multiple llvm modules. Specifically, I want to use scalar evolution on different modules while being able to refer to the results across all modules thus processed. Ideally I don't want to do it as an LTO pass -- I don't know which modules I need to check at the time the program starts running. My current attempt at
2015 Sep 28
3
SourceMgr lifespan
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
2013 Nov 04
0
[LLVMdev] compile error when using overloaded = operator of DenseMap
On Mon, Nov 4, 2013 at 10:35 AM, Rekha R <rekharamapai at nitc.ac.in> wrote: > Hi, > > I am trying to implement Available Expressions data flow analysis. I created > the following class (I am giving here code snippet.): > > namespace { > typedef DenseMap<Expression, uint32_t> DMTy; //Expression is a class I > defined. > struct DataFlowValue { >
2008 Oct 30
6
[LLVMdev] cygwin build problems
Cygwin's <stdint.h> defines uint32_t as "unsigned long". I think this is valid, but it causes various problems like this when building LLVM with GCC 3.4.4: .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3440: error: call of overloaded `AddInteger(uint32_t)' is ambiguous .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1429: error: no matching function for call to `max(long
2014 Jul 17
2
[LLVMdev] LLVM Code Generation on flattened IR code
Hello, I made two flattening transformation filters, one use a switch instruction for the dispatcher, and the other an indirectbranch instruction. Both work well but llc is very time consuming in the second case : 10 minutes for a 500 basic block function, while it takes 10 seconds for the switchcase implementation . The instrumentation of llc shows that most of the time is passed in the Machine