similar to: [LLVMdev] Problem with InsertPointGuard ABI?

Hi all, consider the following function from Core.cpp in LLVM 9.0.0: LLVMValueRef LLVMBuildMalloc(LLVMBuilderRef B, LLVMTypeRef Ty, const char *Name) { Type* ITy = Type::getInt32Ty(unwrap(B)->GetInsertBlock()->getContext()); Constant* AllocSize = ConstantExpr::getSizeOf(unwrap(Ty)); AllocSize = ConstantExpr::getTruncOrBitCast(AllocSize, ITy);

Hi, The IRBuilder is currently templated over a constant folder, and an instruction inserter. https://reviews.llvm.org/D73835 proposes to move this towards using virtual dispatch instead. As this is a larger design change, I would 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

This email is related with the code of commit: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20120409/140650.html. This commit will let our unconditional branch instruction not be deleted when its successor is the nature layout and its basic block's instruction only one instruction. However, I have some concerns about it, especially in the debug mode. Let me show you some

This addition converts strlen() calls to strnlen() when the result is compared to a constant. For example, the following: strlen(s) < 5 Becomes: strnlen(s, 5) < 5 That way, we don't have to walk through the entire string. There is the added overhead of maintaining a counter when using strnlen(), but I thought I'd start with the general case. It may make sense to only use this

Hi, I was compiling libc++ with a recent TOT (248571) and when I got to the ARMv6, I got a code generation error in memory.cpp: fatal error: error in backend: Cannot select: intrinsic %llvm.arm.clrex ecc: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.8.0 (trunk) It looks as if the newly added emitAtomicCmpXchgNoStoreLLBalance() function is

Hello, My code: (CallInst *CI, IRBuilder<> &B) SmallVector<Value *, 8> args; Value *v = B.CreateGlobalString("hi", "str"); args.push_back(v); SmallVector<Type*, 8> params; params.push_back(v->getType()); Module *M = B.GetInsertBlock()->getParent()->getParent(); FunctionType *printfType =

On Fri, Sep 25, 2015 at 2:17 PM, JF Bastien <jfb at google.com> wrote: > Looks like this was caused by r248294. Author CC'ed. > > On Fri, Sep 25, 2015 at 1:46 PM, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I was compiling libc++ with a recent TOT (248571) and when I got to the >> ARMv6, I got a

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 IntegerType *getInt32Ty(LLVMContext &C).

I can confirm that the issue has been caused by NDEBUG flag. On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > The layout of AssertingVH has depended on NDEBUG since 2009, which > predates any of our efforts to make LLVM's ABI resilient to mismatched > NDEBUG definitions between LLVM and its users. > > For now, make sure your definition of NDEBUG

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009,

Attached is a patch for the non ExceptionDemo demos which gets rid of the old const qualifier usage for Type. Although I recently commited the ExceptionDemo changes, I did not want to touch code that I did not "own" without other's approval. Even though trivial, I did not test this patch. Garrison -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi, I am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It is the CreateGlobalStringPtr which is throwing the error. This is LLVM 3.0. Here's the codeI am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It

Probably your g++ compiles x86_64 binary by default, but i686 dylib is supplied? Try: g++ -m32 e.cpp /Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1/libllvmgcc.dylib - D. 2012/1/22 Arpan Sen <arpansen at gmail.com>: > Hi, > > I am trying to use some LLVM API in my C++ code, and I end up getting linker > errors. I am

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,

Hi, That patch was from an ongoing effort to consolidate OpenMP generation in clang. If memory serves the implementation there is still a little incomplete. It's supposed to use types from OMPConstants rather than ones it defined itself and the methods used to create the functions shouldn't need to be static. However attempting this caused a lot of errors so there might be an underlying

Thanks, Joseph and Johannes. I have not merged in anything, I am using the code from the repository as is. What is this -debug-only option, and to whom would I pass it? I am running our own JIT application, which uses clang to compile modules on the fly via clang::CompilerInstance::ExecuteAction(). Working on the assumption that there is a mismatch in the declared type of an OpenMP runtime

Hi all, At the dev meeting I promised to update everyone on where my work with opaque pointers is right now. It's taken me a while, but at least it's the same year! Current Status ============== I've put two branches up at https://github.com/TNorthover/llvm-project: "opaque-ptr" which has most of the real work so far; and "opaque-ptr-always" that additionally has

Yep, it happens three times, then crashes afterwards, since I removed the assert... arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @0 = private unnamed_addr global %struct.ident_t.21 { i32 0, i32 514, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @.str, i32 0, i32 0) }, align 8 arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @1 = private

Yeah, I remember encountering that error before when getting it to pass the libomp test suite. If you have a struct named "ident_t" somewhere the compiler will rename it because of the conflict with the runtime declaration. This should be solved by casting the usage to the function type found in the definition (i.e. bitcasting a struct.ident_t.21 to struct.ident_t) which solved the