llvm dev - Mar 2006 - [LLVMdev] Re: 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/

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.

-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);
 }

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

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.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

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

>> 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/