Chris Lattner
2006-Mar-02 21:23 UTC
[LLVMdev] Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
On Thu, 2 Mar 2006, Vladimir Prus wrote:>>> The instructions seem to have one path wrong. It says to get: >> >> I'll put together a tarball today. That will be easier than dealing with >> a patch, and it will include a bunch of bugfixes since the previous email. > Further into process, I get this error: > In file included from ../../llvm-new-frontend/gcc/llvm-backend.cpp:23: > ../../llvm-new-frontend/gcc/llvm-internal.h:216: error: 'uint64_t' is used > as a type, but is not defined as a type. > > Any ideas what could be wrong?Sorry for the delay, please try this tarball: http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz In addition to fixing the specific error you list above, it also fixes many other things. Please let me know if you have any problems with it! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner
2006-Mar-03 00:36 UTC
[LLVMdev] Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
On Thu, 2 Mar 2006, Chris Lattner wrote:>> Any ideas what could be wrong? > > Sorry for the delay, please try this tarball: > http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gzActually, do to a recent change in CVS, this tarball will probably not work anymore. Please apply the attached (small) patch on top of it in the gcc directory. Worth noting, this front-end only works with LLVM mainline, not LLVM 1.6. -Chris -- http://nondot.org/sabre/ http://llvm.org/ -------------- next part -------------- Index: llvm-convert.cpp ==================================================================--- llvm-convert.cpp (revision 111673) +++ llvm-convert.cpp (working copy) @@ -795,14 +795,18 @@ void TreeToLLVM::EmitMemCpy(Value *DestP unsigned Align) { const Type *SBP = PointerType::get(Type::SByteTy); static Function *MemCpy = 0; - if (!MemCpy) - MemCpy = TheModule->getOrInsertFunction("llvm.memcpy", Type::VoidTy, SBP, - SBP, Type::UIntTy, Type::UIntTy, + const Type *IntPtr = TD.getIntPtrType(); + if (!MemCpy) { + const char *Name = IntPtr == Type::UIntTy ? + "llvm.memcpy.i32" : "llvm.memcpy.i64"; + MemCpy = TheModule->getOrInsertFunction(Name, Type::VoidTy, SBP, + SBP, IntPtr, Type::UIntTy, NULL); + } std::vector<Value*> Ops; Ops.push_back(CastToType(DestPtr, SBP)); Ops.push_back(CastToType(SrcPtr, SBP)); - Ops.push_back(CastToType(Size, Type::UIntTy)); + Ops.push_back(CastToType(Size, IntPtr)); Ops.push_back(ConstantUInt::get(Type::UIntTy, Align)); new CallInst(MemCpy, Ops, "", CurBB); } @@ -811,14 +815,17 @@ void TreeToLLVM::EmitMemMove(Value *Dest unsigned Align) { const Type *SBP = PointerType::get(Type::SByteTy); static Function *MemMove = 0; - if (!MemMove) - MemMove = TheModule->getOrInsertFunction("llvm.memmove", Type::VoidTy, SBP, - SBP, Type::UIntTy, Type::UIntTy, - NULL); + const Type *IntPtr = TD.getIntPtrType(); + if (!MemMove) { + const char *Name = IntPtr == Type::UIntTy ? + "llvm.memmove.i32" : "llvm.memmove.i64"; + MemMove = TheModule->getOrInsertFunction(Name, Type::VoidTy, SBP, SBP, + IntPtr, Type::UIntTy, NULL); + } std::vector<Value*> Ops; Ops.push_back(CastToType(DestPtr, SBP)); Ops.push_back(CastToType(SrcPtr, SBP)); - Ops.push_back(CastToType(Size, Type::UIntTy)); + Ops.push_back(CastToType(Size, IntPtr)); Ops.push_back(ConstantUInt::get(Type::UIntTy, Align)); new CallInst(MemMove, Ops, "", CurBB); } @@ -827,14 +834,18 @@ void TreeToLLVM::EmitMemSet(Value *DestP unsigned Align) { const Type *SBP = PointerType::get(Type::SByteTy); static Function *MemSet = 0; - if (!MemSet) - MemSet = TheModule->getOrInsertFunction("llvm.memset", Type::VoidTy, SBP, - Type::UByteTy, Type::UIntTy, + const Type *IntPtr = TD.getIntPtrType(); + if (!MemSet) { + const char *Name = IntPtr == Type::UIntTy ? + "llvm.memset.i32" : "llvm.memset.i64"; + MemSet = TheModule->getOrInsertFunction(Name, Type::VoidTy, SBP, + Type::UByteTy, IntPtr, Type::UIntTy, NULL); + } std::vector<Value*> Ops; Ops.push_back(CastToType(DestPtr, SBP)); Ops.push_back(CastToType(SrcVal, Type::UByteTy)); - Ops.push_back(CastToType(Size, Type::UIntTy)); + Ops.push_back(CastToType(Size, IntPtr)); Ops.push_back(ConstantUInt::get(Type::UIntTy, Align)); new CallInst(MemSet, Ops, "", CurBB); }
Vladimir Prus
2006-Mar-06 15:13 UTC
[LLVMdev] Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
Chris Lattner wrote:> On Thu, 2 Mar 2006, Chris Lattner wrote: >>> Any ideas what could be wrong? >> >> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > Actually, do to a recent change in CVS, this tarball will probably not > work anymore. Please apply the attached (small) patch on top of it in > the gcc directory. > > Worth noting, this front-end only works with LLVM mainline, not LLVM 1.6.Without the patch, I get this: TreeToLLVM::StartFunctionBody()': ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:344: warning: statement with no effect ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp: At global scope: ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1305: error: parse error before `__attribute__' ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp: In function `tree_node* StripLLVMTranslationFn(...)': ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1312: error: `I' undeclared (first use this function) ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1312: error: (Each undeclared identifier is reported only once for each function it appears in.) ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1312: error: ISO C++ forbids declaration of `tsi_next' with no type ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1312: error: `int tsi_next' With the patch, I get exactly the same error. The configure command was: ../2006-03-02-llvm-gcc-4/configure --enable-languages=c,c++ --enable-llvm=/space/p2/ghost/build/llvm-cvs/install --prefix=`pwd`/install --program-prefix=llvm- and my LLVM is CVS state as of Friday. Any suggestions? - Volodya
Vladimir Prus
2006-Mar-07 07:53 UTC
[LLVMdev] Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
Chris Lattner wrote:> On Thu, 2 Mar 2006, Vladimir Prus wrote: >>>> The instructions seem to have one path wrong. It says to get: >>> >>> I'll put together a tarball today. That will be easier than dealing >>> with a patch, and it will include a bunch of bugfixes since the previous >>> email. >> Further into process, I get this error: >> In file included from ../../llvm-new-frontend/gcc/llvm-backend.cpp:23: >> ../../llvm-new-frontend/gcc/llvm-internal.h:216: error: 'uint64_t' is >> used as a type, but is not defined as a type. >> >> Any ideas what could be wrong? > > Sorry for the delay, please try this tarball: > http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gzThere's some confusion with --enable-llvm configure parameter. I've built LLVM to a separate build dir. The source is ~ghost/Work/llvm-cvs and build dir is /space/p2/ghost/build/llvm-cvs I've configured LLVM with prefix=/space/p2/ghost/build/llvm-cvs/install and run "make install". Now, if, when configuring frontend, I specify --enable-llvm=/space/p2/ghost/build/llvm-cvs I get error because no LLVM header can be found. If I specify --enable-llvm=/space/p2/ghost/build/llvm-cvs/install I get link errors like this: c++: /space/p2/ghost/build/llvm-cvs/install/Debug/lib/LLVMX86.o: No such file or directory So, it seems like, at the same time: 1. buildir != srcdir is not supported when building frontend 2. building the frontend against installed LLVM does not work either. I can get past the compile/link errors only after copying "include" directory from source dir to the build dir. Then, I'm faced with yet another problem, sorry! The problem is: /space/p2/ghost/build/llvm-frontend/gcc/xgcc -B/space/p2/ghost/build/llvm-frontend/gcc/ -B/space/p2/ghost/build/llvm-frontend/install/i686-pc-linux-gnu/bin/ -B/space/p2/ghost/build/llvm-frontend/install/i686-pc-linux-gnu/lib/ -isystem /space/p2/ghost/build/llvm-frontend/install/i686-pc-linux-gnu/include -isystem /space/p2/ghost/build/llvm-frontend/install/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../2006-03-02-llvm-gcc-4/gcc -I../../2006-03-02-llvm-gcc-4/gcc/. -I../../2006-03-02-llvm-gcc-4/gcc/../include -I../../2006-03-02-llvm-gcc-4/gcc/../libcpp/include -I/space/p2/ghost/build/llvm-cvs/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../2006-03-02-llvm-gcc-4/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O \ -o crtbeginT.o In file included from ../../2006-03-02-llvm-gcc-4/gcc/crtstuff.c:67: ../../2006-03-02-llvm-gcc-4/gcc/unwind-dw2-fde.h: In function 'get_cie': ../../2006-03-02-llvm-gcc-4/gcc/unwind-dw2-fde.h:163: warning: return from incompatible pointer type Invalid operand found in inline asm: 'call .LPR0 .LPR0: popl $0 addl $$_GLOBAL_OFFSET_TABLE_+[.-.LPR0],$0' INLINEASM <es:call .LPR0 .LPR0: popl $0 addl $$_GLOBAL_OFFSET_TABLE_+[.-.LPR0],$0>, 10, %DX<def> make[1]: *** [crtbeginT.o] Error 1 make[1]: Leaving directory `/space/p2/ghost/build/llvm-frontend/gcc' This time, I don't even understand what I'm told. Note that cc1plus is already built by the time this error is emitted. Can you suggest something? - Volodya
Chris Lattner
2006-Mar-15 02:27 UTC
[LLVMdev] Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
>> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > There's some confusion with --enable-llvm configure parameter. I've built > LLVM to a separate build dir. The source is ~ghost/Work/llvm-cvs and build > dir is /space/p2/ghost/build/llvm-cvs...> So, it seems like, at the same time: > > 1. buildir != srcdir is not supported when building frontend > 2. building the frontend against installed LLVM does not work either.Correct. I currently only build the front-end against a built, but not installed, LLVM tree with srcdir = objdir. If you would like to tackle this problem and propose a patch, I would be happy to apply it, but I have other projects to work on now :)> Then, I'm faced with yet another problem, sorry! The problem is: > > incompatible pointer type > Invalid operand found in inline asm: 'call .LPR0...> This time, I don't even understand what I'm told. Note that cc1plus is > already built by the time this error is emitted. > Can you suggest something?Here's a new snapshot of the front-end: http://nondot.org/sabre/2006-03-14-llvm-gcc-4.tar.gz This: 1. Fixes the inline asm problem you have above. 2. Includes patches to make it better on Alpha's (thanks to patches by Andrew Lenharth). 3. Sync's it up with debug info changes in LLVM CVS (by Jim Laskey). 4. Has initial support for target-specific intrinsics, through Intrinsics.td. Please give it a try and let me know if it works any better for you! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Apparently Analagous Threads
- [LLVMdev] Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
- [LLVMdev] Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
- [LLVMdev] Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
- [LLVMdev] Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
- [LLVMdev] problem building gcc4 front end on fedora core 5