search for: irbuilderbase

Hi, I have problem with IRBuilderBase::InsertPointGuard class that simply does not work in the release build of my project. The class does not restore the IRBuilder's insert point correctly when NDEBUG macro is set. It happens on OSX system only, trunk version of the LLVM built with brew. I suspect it is the ABI problem. InsertPoi...

...like to get some feedback on this. The current templated design of IRBuilder has a couple of problems: 1. It's not possible to share code between use-sites that use different IRBuilder folders/inserters (short of templating the code and moving it into headers). 2. Methods currently defined on IRBuilderBase (which is not templated) do not use the custom inserter, resulting in subtle bugs (e.g. incorrect InstCombine worklist management). It would be possible to move those into the templated IRBuilder, but... 3. The vast majority of the IRBuilder implementation has to live in the header, because it depe...

Sorry, these IRBuilder methods are really in IRBuilderBase. Garrison On Jul 11, 2011, at 11:54, Garrison Venn wrote: > Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have > their return type const qualifiers removed? Doing so would match the semi equivalent static > methods of Type, such as static Int...

...plication/octet-stream Size: 4224 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110711/45919a85/attachment.obj> -------------- next part -------------- On Jul 11, 2011, at 12:00, Garrison Venn wrote: > Sorry, these IRBuilder methods are really in IRBuilderBase. > > Garrison > > On Jul 11, 2011, at 11:54, Garrison Venn wrote: > >> Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have >> their return type const qualifiers removed? Doing so would match the semi equivalent static >&gt...

...mentPtrInst::init(llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::Twine const&)", referenced from: llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, llvm::ArrayRef<llvm::Value*>, unsigned int, llvm::Twine const&, llvm::Instruction*)in ccFB7xjg.o "llvm::IRBuilderBase::CreateGlobalString(llvm::StringRef, llvm::Twine const&)", referenced from: llvm::IRBuilder<true, llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true> >::CreateGlobalStringPtr(llvm::StringRef, llvm::Twine const&)in ccFB7xjg.o "llvm::ConstantInt::get(llvm:...

...alue*, llvm::ArrayRef<llvm::Value*>, > llvm::Twine const&)", referenced from: > llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, > llvm::ArrayRef<llvm::Value*>, unsigned int, llvm::Twine const&, > llvm::Instruction*)in ccFB7xjg.o > "llvm::IRBuilderBase::CreateGlobalString(llvm::StringRef, llvm::Twine > const&)", referenced from: > llvm::IRBuilder<true, llvm::ConstantFolder, > llvm::IRBuilderDefaultInserter<true> >>::CreateGlobalStringPtr(llvm::StringRef, llvm::Twine const&)in ccFB7xjg.o > "llvm...

...Lowering::getTgtMemIntrinsic 12 getVectorType 12 llvm::ConstantFoldGetElementPtr 11 llvm::IRBuilderBase::CreateMaskedLoad 9 llvm::TargetLowering::LowerCallTo 7 llvm::InterleavedAccessInfo::collectConstStrideAccesses 7 llvm::IRBuild...

...e/llvm/IR/Instructions.h:1681 > #5 0x00007fb7116a9cf2 in llvm::CallInst::Create (Ty=0x51fd280, > Func=0x51f6d28, Args=..., Bundles=..., NameStr=..., > InsertBefore=0x0) at > /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/Instructions.h:1489 > #6 0x00007fb71171f1e0 in llvm::IRBuilderBase::CreateCall > (this=0x7fffd4fdaac8, FTy=0x51fd280, Callee=0x51f6d28, Args=..., > OpBundles=..., Name=..., FPMathTag=0x0) at > /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2338 > #7 0x00007fb71171f2d5 in llvm::IRBuilderBase::CreateCall > (this=0x7fffd4fdaac8, C...

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to

...ns.h:1681 >> #5 0x00007fb7116a9cf2 in llvm::CallInst::Create (Ty=0x51fd280, >> Func=0x51f6d28, Args=..., Bundles=..., NameStr=..., >> InsertBefore=0x0) at >> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/Instructions.h:1489 >> #6 0x00007fb71171f1e0 in llvm::IRBuilderBase::CreateCall >> (this=0x7fffd4fdaac8, FTy=0x51fd280, Callee=0x51f6d28, Args=..., >> OpBundles=..., Name=..., FPMathTag=0x0) at >> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2338 >> #7 0x00007fb71171f2d5 in llvm::IRBuilderBase::CreateCall >> (th...

Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have their return type const qualifiers removed? Doing so would match the semi equivalent static methods of Type, such as static IntegerType *getInt32Ty(LLVMContext &C). Thanks in advance Garrison On Jul 9, 2011, at 3:35, Chris Lattner wrote: > FYI, the type-system-rewrite branch is landing

...9cf2 in llvm::CallInst::Create (Ty=0x51fd280, > >>> Func=0x51f6d28, Args=..., Bundles=..., NameStr=..., > >>> InsertBefore=0x0) at > >>> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/Instructions.h:1489 > >>> #6 0x00007fb71171f1e0 in llvm::IRBuilderBase::CreateCall > >>> (this=0x7fffd4fdaac8, FTy=0x51fd280, Callee=0x51f6d28, Args=..., > >>> OpBundles=..., Name=..., FPMathTag=0x0) at > >>> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2338 > >>> #7 0x00007fb71171f2d5 in llvm::I...

Hi George, > This is the seg fault I am getting. > > dyld: lazy symbol binding failed: Symbol not found: > __ZN4llvm13IRBuilderBase18CreateGlobalStringEPKcRKNS_5TwineE > Referenced from: > /Users/georgebaah/llvm_dir/llvm-2.8/Debug+Asserts/lib/LLVMArrayBoundsCheck.dylib > Expected in: flat namespace > > dyld: Symbol not found: __ZN4llvm13IRBuilderBase18CreateGlobalStringEPKcRKNS_5TwineE > Referenced fr...

...y=0x51fd280, > >>>>> Func=0x51f6d28, Args=..., Bundles=..., NameStr=..., > >>>>> InsertBefore=0x0) at > >>>>> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/Instructions.h:1489 > >>>>> #6 0x00007fb71171f1e0 in llvm::IRBuilderBase::CreateCall > >>>>> (this=0x7fffd4fdaac8, FTy=0x51fd280, Callee=0x51f6d28, Args=..., > >>>>> OpBundles=..., Name=..., FPMathTag=0x0) at > >>>>> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2338 > >>>>>...

...>>>>>>> Func=0x51f6d28, Args=..., Bundles=..., NameStr=..., >>>>>>> InsertBefore=0x0) at >>>>>>> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/Instructions.h:1489 >>>>>>> #6 0x00007fb71171f1e0 in llvm::IRBuilderBase::CreateCall >>>>>>> (this=0x7fffd4fdaac8, FTy=0x51fd280, Callee=0x51f6d28, Args=..., >>>>>>> OpBundles=..., Name=..., FPMathTag=0x0) at >>>>>>> /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2338 >>>>...

FYI, the type-system-rewrite branch is landing tomorrow morning, in mainline llvm, llvm-gcc and clang. I don't have updates, so dragonegg will have to remain broken until someone can fix it (the changes aren't too terrible, llvm-gcc is a good template). If you're interested in an early preview, the type-system-rewrite branch contains the code for llvm and clang. I sent the llvm-gcc

...4 libc.so.6 0x00002aaaab8cdf70 abort + 384 5 libc.so.6 0x00002aaaab8c42b1 __assert_fail + 241 6 clang 0x0000000001d799dc llvm::Intrinsic::getDeclaration(llvm::Module*, llvm::Intrinsic::ID, llvm::ArrayRef<llvm::Type*>) + 172 7 clang 0x0000000001da8476 llvm::IRBuilderBase::CreateMemCpy(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int, bool, llvm::MDNode*) + 278 8 clang 0x0000000000917059 clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::FunctionDecl const*, unsigned int, clang::CallExpr const*) + 13001 9 clang 0x000000000085491c cla...

This is the seg fault I am getting. dyld: lazy symbol binding failed: Symbol not found: __ZN4llvm13IRBuilderBase18CreateGlobalStringEPKcRKNS_5TwineE Referenced from: /Users/georgebaah/llvm_dir/llvm-2.8/Debug+Asserts/lib/LLVMArrayBoundsCheck.dylib Expected in: flat namespace dyld: Symbol not found: __ZN4llvm13IRBuilderBase18CreateGlobalStringEPKcRKNS_5TwineE Referenced from: /Users/georgebaah/llvm_dir/l...

Thank you Chris. I am using llvm-3.4.2. I am facing the same issue when using clang++ as well. $ clang++ try.cpp -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS `llvm-config --cxxflags --ldflags --libs` -S -emit-llvm gives me errors $clang++ try.cpp -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -S -emit-llvm $ lli try.s gives me Program used external function

Hi there, At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. For example: - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 Unfortunately all these