search for: intrusiverefcntptrs

When trying to build the 11.0-CURRENT clang 3.5 on powerpc64 I ran into a violation of C++ accessibility rules (for private) that stopped the compile. So not the usual defect category. (This was a bootstrapping procedure as powerpc/powerpc64 FreeBSD world’s clang has an odd status and getting from 3.4 under 10.1-STABLE to 3.5 on 11.0-CURRENT is not automatic.) Given the language rules and

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());

On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > In terms of performance shared_ptr has a number of disadvantages. One > is that it always uses atomics even though most IntrusiveRefCntPtrs > are used in single-threaded contexts. Another is weak_ptr adding a lot > of complexity to the implementation, IntrusiveRefCntPtr doesn't > support weak references. > > With that it's hard to make a case for changing uses of > IntrusiveRefCntPtr as it's a non-trivial...

...llvm-dev at lists.llvm.org> wrote: > > On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In terms of performance shared_ptr has a number of disadvantages. One >> is that it always uses atomics even though most IntrusiveRefCntPtrs >> are used in single-threaded contexts. Another is weak_ptr adding a lot >> of complexity to the implementation, IntrusiveRefCntPtr doesn't >> support weak references. >> >> With that it's hard to make a case for changing uses of >> IntrusiveRefCntPtr as...

Hi, On 2020-10-01 15:29:12 -0700, Lang Hames wrote: > 24bytes / object -- Looks like I managed module ownership correctly but > leaked the ThreadSafeModule container. This should be fixed in 5044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

I am using the clang API (version 3.1 - trunk 153913) to compile some very simple code as follows class MyClass { ~MyClass() ; }; MyClass::~MyClass() { } int main() { return 0; } My problem is that I get the error message: test.cpp:20:10: error: destructor cannot have a return type MyClass::~MyClass() If someone can point me to the right direction that would be great. It compiles fine if

Thanks Dimitry. That worked. I see some warnings in my compilations: > Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/IntEqClasses.cpp.o > [ 2%] clang-3: warning: argument unused during compilation: '-nostdinc++' > Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/IntrusiveRefCntPtr.cpp.o > clang-3: warning: argument unused during compilation:

On Fri, Sep 21, 2012 at 12:22 PM, Kamaljit Lall <klall at factset.com> wrote: > I am using the clang API (version 3.1 - trunk 153913) to compile some > very simple code as follows**** > > class MyClass > { > ~MyClass() ; > > }; > > MyClass::~MyClass() > { > > } > > int main() > { > return 0; > } **** > > My problem is that

Manuel, After the discussion at last night, I have agreed that GetTemporaryDirectory() on Win32 would do bad thing, thank you. dir = GetTemporaryDirectory(); dir.eraseFromDisk(erase_contents = true); dir = GetTemporaryDirectory(); /* It doesn't create anything on Win32 due to caching */ I suppose Manuel wants GetTemporaryDirectory() to keep semantics similar mkdtemp(3). Though it is in

Hi, I'm not sure if this is a libclang, llvm::cl or clang-interpreter issue so I'll try posting here for a response. I am using libclang as a frontend to the LLVM JIT (3.3 release). I started from the clang-interpreter example and have everything working (given a C/C++ source file I can have it JIT'd to memory and executed) for a single run. When I try to compile a second source

Hi, I have downloaded version 3.0 of LLVM and Clang and built them as shared libraries (on Windows, Linux and Mac OS X) using the following steps: cd <WHERE-llvm-3.0.tar.gz-IS> tar xvzf llvm-3.0.tar.gz cd llvm-3.0.src/tools tar xvzf ../../clang-3.0.tar.gz mv clang-3.0.src clang cd ../.. mkdir build cd build ../llvm-3.0.src/configure --disable-docs --enable-shared

On 2012-06-26 04:22, Ashok Nalkund wrote: ... >> /local/mnt/workspace/ashoknn/519_libcxx_transition/llvm/src/tools/bugpoint/ToolRunner.cpp:131:12: error: invalid operands to binary expression ('llvm::raw_ostream' and 'std::ostringstream' >> (aka 'basic_ostringstream<char>')) >> errs() << OS; >> ~~~~~~ ^ ~~ > Hi Ashok,

Hi All, I'm using LLVM/Clang 3.1 release. I first compiled llvm/clang using GCC per the instructions on the web with cmake. I then compiled libc++ per the instructions on the web. I then tried to compile llvm/clang with previously compiled clang and libc++ using "-std=c++0x -stdlib=libc++" flags. But the compilation fails at: > [ 58%] Building CXX object

Hi Ashok, $ cd bin/bin $ ./llvm-config --ldflags --libs -L/home/ubuntu/bin/lib   -ldl -lpthread -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInstrumentation -lLLVMInterpreter

You will need to link to the LLVM/clang libraries. To get the correct flags, you can run: ./llvm-config --ldflags --libs and use the flags reported. On 7/10/2012 11:35 AM, NY Knicks Fan wrote: > OK. Thanks. I now get the following error (which appears to be a > problem w/ the tutorial itself?): > > $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/ >

You need to link in the libclang* as well. On 7/10/2012 1:22 PM, NY Knicks Fan wrote: > Hi Ashok, > > $ cd bin/bin > $ ./llvm-config --ldflags --libs > -L/home/ubuntu/bin/lib -ldl -lpthread > -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMX86Disassembler > -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter > -lLLVMX86Desc -lLLVMX86Info

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,