similar to: [LLVMdev] linking standard c++ functions @_Znam and @_Znwm

Hi Ali, On 14/01/13 07:11, Ali Sedaghat wrote: > I'm new to c++ programming and currently working on an |llvm| front-end > development project. When I link the object files created by llc, my linker > cannot locate the following functions. what is the exact command you are using to link? Ciao, Duncan. I know that these are standard c++ > library functions but g++ cannot

I'm developing an llvm-based compiler and when I try to generate executable file the following error occurs: ./bin/llvmcode.s:35: undefined reference to `operator new[](unsigned long)' Note that in the generated IR, the function '@_Znam' is called which is located in one of llvm libraries. So, I should have linked the generated assembly file with that library. Here is the code I

On Wed, Jan 9, 2013 at 5:32 AM, Ali Sedaghat <ali.sedaghatbaf at gmail.com> wrote: > I'm developing an llvm-based compiler and when I try to generate > executable file the following error occurs: > > ./bin/llvmcode.s:35: undefined reference to `operator new[](unsigned > long)' > > Note that in the generated IR, the function '@_Znam' is called which is

when I compile llvm-3.3 according to the instructions in vmkit's homepage the following error occurs: llvm-3.3.src/Release+Asserts/lib/libclangAST.a(VTableBuilder.o): In function `(anonymous namespace)::VCallAndVBaseOffsetBuilder::AddVCallOffsets(clang::BaseSubobject, clang::CharUnits)': VTableBuilder.cpp:(.text+0xc6c3): undefined reference to

when I execute clang on llvm bitcode files, I get the following error: clang: error: unable to execute command: Aborted unsupported GC: vmkit UNREACHABLE executed at GCMetadata.cpp:87! 0 clang 0x09e9d5d9 llvm::sys::PrintStackTrace(_IO_FILE*) + 41 Stack dump: 0. Program arguments: /home/ali/llvm-3.3.src/Release+Asserts/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all

On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk>wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >> >>> Hi, >>> >>> LLVM classifies _Znwm as a builtin by default. After some

On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: > Hi, > > LLVM classifies _Znwm as a builtin by default. After some discussion, the > C++ core working group have decreed that that is not correct: calls to > "operator new" *can* be optimized, but only if they come from > new-expressions, and not if they come from explicit calls to

On Wed, May 15, 2013 at 9:28 PM, Richard Smith <richard at metafoo.co.uk>wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >> >>> Hi, >>> >>> LLVM classifies _Znwm as a builtin by default. After some

On Wed, May 15, 2013 at 8:46 PM, Chris Lattner <clattner at apple.com> wrote: > On May 15, 2013, at 8:44 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk>wrote: > >> On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> On Wed,

On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: > >> Hi, >> >> LLVM classifies _Znwm as a builtin by default. After some discussion, the >> C++ core working group have decreed that that is not correct: calls to >> "operator

Hi, LLVM classifies _Znwm as a builtin by default. After some discussion, the C++ core working group have decreed that that is not correct: calls to "operator new" *can* be optimized, but only if they come from new-expressions, and not if they come from explicit calls to ::operator new. We cannot work around this in the frontend by marking the call as 'nobuiltin' for two

On May 15, 2013, at 8:44 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Hi, > > LLVM classifies

On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >>>>> (see recent patch on llvmcommits) >>>>> 2) We can't block the optimization if the call

On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) >> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >>

On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits)

On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits)

On Wed, May 15, 2013 at 9:46 PM, Chris Lattner <clattner at apple.com> wrote: > It's not clear to me that "builtin" is the right way to model this, but it > definitely sounds like this should be an attribute on a call site (as > opposed to on the function itself). What specific kinds of optimizations > are we interested in doing to _Znwm calls? You can see the

Hi, Can you please help me with this please? What I am trying to do is call a vector from R function and used in the new function So I create 4 functions with these arguments M11 <- function(TrainData,TestData,mdat,nsam) { ls <- list() I have few statments one of them is vectx <- c(,1,2,3,4,5,6,6) vectz <- c(12,34,5,6,78,9,90) and then................ ls(vectx=vtecx,vectz=vectz)

In order to print unicode characters with llvm, I used setLocale in llvm ir: call i8* @setlocale(i32 6, i8* getelementptr inbounds ([1 x i8]* @pe, i32 0, i32 0)) nounwind where @pe is defined as follows: @pe = private unnamed_addr constant [1 x i8] zeroinitializer, align 1 However, I got the following error: *** glibc detected *** ./test/bin/executable: free(): invalid next size

On Wed, May 15, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> >> 1)