similar to: [LLVMdev] nested GEP in a static initializer fails

Joel E. Denny wrote: > Hi, > > Given this LLVM assembly: > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* getelementptr (i32* null, i32 1) to i64), i64 2)) > > llc fails an assertion: > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =

Hi Nick, On Tue, 26 Oct 2010, Nick Lewycky wrote: > Joel E. Denny wrote: > > Given this LLVM assembly: > > > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* > > getelementptr (i32* null, i32 1) to i64), i64 2)) > > > > llc fails an assertion: > > > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202:

On Thu, Oct 28, 2010 at 3:47 PM, Joel E. Denny <jdenny at etinternational.com> wrote: > For example, for my platform, llc folds the add but not the getelementptr > in: > >  @a = global i8* getelementptr (i8* null, i64 add (i64 3, i64 2)) This gets folded when it's read in; there's no other way to represent a constant 'i64 add (i64 3, i64 2)' in LLVM than 'i64

> ... and it's in.  Please let me know if you see any problems. My clang self-hosted build (Release+Asserts on Release+Asserts, Linux x86_64) fails with: make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: typename

Jay Foad wrote: >> ... and it's in. Please let me know if you see any problems. > > My clang self-hosted build (Release+Asserts on Release+Asserts, Linux > x86_64) fails with: > > make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' > llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build > clang:

On Jul 9, 2011, at 12:35 AM, Chris Lattner wrote: > 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

Hello; Thanks to Eli for the pointer to the ConstantDataArray::getString() fucntion. Now I am trying to declare a global char array with the content "hi" and call a function "print" (which takes a char pointer and return an insteger. I am doing the following in the code - Function Creation: PointerType* array = PointerType::get(IntegerType::getInt8Ty(getGlobalContext())

Thanks, Shahid. It is fixed now. On Fri, Apr 17, 2015 at 8:50 PM, Shahid, Asghar-ahmad < Asghar-ahmad.Shahid at amd.com> wrote: > Hi zhi, > > > > You have to also pass the value type to getDecalaration() API such as > > > > Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd, > v->getType()); > > > > Regards, > >

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

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

I am running the following llvm-ld command to produce native code: llvm-ld -native -o code.exe code.bc -lm However, I am getting the following assertion failure in llc. The bytecode has been processed with opt, it passes opt bytecode verification. I'm not too familiar with backend code generation. Does anyone have any insight in to what the problem might be or how to go about

Hello, I have a problem of generating a load instruction. The LLVM bytecode is: ------------------------ entry: ... %2 = call i32 (...)* @atoi(i8*%1) nounwind /*<- Insertpos*/ ... -- bb1: .. %5 = icmp sgt i32 %2, %i.0 ... ----------------- Now I have pb: pointer to the Value object of *%2* of bb1. Here, I want to generate a load instruction and I did it as: new LoadInst(pb,

Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry

>From r167602 and onwards I get a fail in 'make check-all' for llvm+clang, built with gcc-4.7.1 (but not with clang-3.1) on Linux x86_64: Failing Tests (1): Clang :: CodeGenCXX/mangle-ms-templates.cpp clang: /dev/shm/uabpath/master/include/llvm/Support/Casting.h:208: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =

Hi Ryan, On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > I am running the following llvm-ld command to produce native code: > > llvm-ld -native -o code.exe code.bc -lm > > However, I am getting the following assertion failure in llc. The > bytecode has been processed with opt, it passes opt bytecode > verification. I'm not too familiar with backend

opt: /home/ryan/llvm/llvm_core/llvm-3.0/include/llvm/Support/Casting.h:194: typename cast_retty<Instruction, User *>::ret_type llvm::cast(llvm::User *const &): Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. 0 opt 0x000000000085cfef 1 opt 0x000000000085d509 2 libpthread.so.0 0x00007fdb30054c60 3

Hi all, at the moment I am trying to fix an unnecessary iterator dereferencing in Casting.h and am uncovering several ugly things. For example, look at this code: > // dyn_cast_or_null<X> - Functionally identical to dyn_cast, except that a null > // value is accepted. > // > template <class X, class Y> > inline typename cast_retty<X, Y>::ret_type

Hi, I have: int main() { int i = 1; } in test.c. Then: llvm-gcc -emit-llvm -O0 -c test.c -o test.bc -g llc -march=cpp test.bc gives me: LLVM ERROR: Invalid primitive type This only happens when I use the "-g". Is this a bug? Thanks, Guoliang

Is a PR a bug report on the bugzilla database? I am also running bugpoint to see if that yields anything. Reid Spencer wrote: > Hi Ryan, > > On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > >>I am running the following llvm-ld command to produce native code: >> >>llvm-ld -native -o code.exe code.bc -lm >> >>However, I am getting the