similar to: 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:

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

I was looking at the SymbolTable code in LLD COFF and ELF recently, and I’m confused by the use of CachedHashStringRef. From what I understand, a CachedHashStringRef combines a StringRef with a computed hash. There’s no caching going on in the CachedHashStringRef itself; that is, if you construct CachedHashStringRef("foo"), and then construct a second

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

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Hi all, I'm dealing with the multi-threaded code, in one of executions of the program I hitting an assertion failure, I'm not always getting the assertion failure when I run the executable but it occurs for say (1 in 10) times. I think there may be an thread race condition. I don't know which is the root cause of this error because the assertion not explicitly occurs in my code, it

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 { DMTy ExprMap; llvm::BitVector* DFV; // Functions operating on the data // bool operator==(const DataFlowValue V) const;

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

The asan bootstrap bot is unhappy with lld. Rui, os someone, please take a look. http://lab.llvm.org:8011/builders/sanitizer-x86_64- linux-bootstrap/builds/138/steps/check-lld%20asan/logs/stdio ==26011==ERROR: LeakSanitizer: detected memory leaks Direct leak of 184 byte(s) in 1 object(s) allocated from: #0 0x72fab0 in operator new(unsigned long)

On Mon, Nov 7, 2016 at 5:53 PM, Davide Italiano <davide at freebsd.org> wrote: > On Mon, Nov 7, 2016 at 4:43 PM, Kostya Serebryany via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> The asan bootstrap bot is unhappy with lld. >> Rui, os someone, please take a look. >> >>

Hello, I am trying to run this basic C++ hello-world code in my iOS app that has LLVM libraries linked in (the app runs on the actual device - iPad Pro, iOS 13.4.1). #include <iostream> int main (int argh, char *argv[]) { std::cout << "Hello World!" << std::endl; return 0; } So below is the break down of the steps that I do: First I compile this code to an

I'm having issues of my compiler, and JIT execution, of LLVM IR being rather slow. It's accounting for the vast majority of my full compilation time.  I'm trying to figure out why this is happening, since it's becoming an impediment.  (Note: by slow I mean about 3s of time for only about 2K of my front-end code, 65K lines of LLVM-IR) Using valgrind I see some functions which seem

Hi Dave, Yep. This is JITLink specific, so we could only have observed it on MachO x86-64 or arm64 until recently. It takes a little bit of poking to get IR to produce a zero-lengh section on MachO, but not much. Jared Wyles recently contributed an initial JITLink ELF implementation, so the fix seems timely -- we might have been about to see more of it. -- Lang. On Fri, Jun 19, 2020 at 4:02 PM

Hi Lang, Please see below is the trace. -- Thanks, Igor *2020-06-06 12:05:21.016705-0400 CppDevProCompiler[6613:3000073] Running...* *jitLink_MachO: magic = 0xfeedfacf, identifier = "llvm-link.submodule-jitted-objectbuffer"* *jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000* *Creating normalized sections...* * __text: 0x0000000000000000 -- 0x0000000000000064, align:

Hi, Could you share how you compile IR and which version of JIT you use (Orc, MCJIT)? Could it be that you are using interpreter instead of actual JIT? Cheers, Alex. > On 5. May 2018, at 08:04, edA-qa mort-ora-y via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm having issues of my compiler, and JIT execution, of LLVM IR being > rather slow. It's accounting for

I've been trying to get oprofile results for jitted code without success. I built an 3.5.0 llvm with oprofile enabled, and tested it with lli on a small test case. I built the latest oprofile from the git repository. Debugging I can see that lli is registering the listener and making the oprofile calls to the libopagent api to specify the names and address ranges of jit'd routines, and

Mi Maurice, A follow up to Andy's comments: MCJIT can find line numbers for ELF files, at least in limited circumstances. I know because I broke the regression test for it while doing some cleanup recently. ;) Looking at lib/ExecutionEngine/OProfileJIT/OProfileJITEventListener.cpp, I see the line: // TODO: support line number info (similar to IntelJITEventListener.cpp) >From a glance at

On Thu, 26 Sep 2019, David Blaikie wrote: > I'd be surprised if Clang or GCC's behavior here varied depending on the > size of anything, but maybe? > > In any case, C++17 or so requires the RHS to be evaluated before the LHS for > assignments - so this is now /always/ wrong, not just unspecified (which, I > guess, also always wrong... just sometimes accidentally right)

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

I really can't figure out how to get and set array indices from the c interface. so to get an element I'm calling tindex = *fn\SymbolTable(*index\name) index = LLVMBuildLoad(builder,tindex,"index") arr = *fn\SymbolTable(*array\name) arrptr = LLVMBuildLoad(Builder,arr,"arrayptr") tmp = LLVMBuildGEP(Builder,arrptr,index,0,"ptr") ptr =