llvm dev - Mar 2006 - [LLVMdev] Re: Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM

On Thu, 16 Mar 2006, Vladimir Prus wrote:
> Ah, hell, as soon as I've send this email I've updated from CVS to
find that
> the issue was fixed by Jim several hours after I reported the crash, by
> making MachineDebugInfo don't check for empty name of type.
:)
> Here's what I get now:
>
>
/space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h:42:
> internal compiler error: in make_decl_rtl, at varasm.c:1018
> (gdb) where
> Preprocessed source goes by private email.
Great, thanks for the info.  Please try this patch:

Index: varasm.c
==================================================================--- varasm.c  
(revision 112246)
+++ varasm.c    (working copy)
@@ -4759,6 +4759,13 @@ assemble_alias (tree decl, tree target)
      }
  # endif
  #endif
+
+  /* APPLE LOCAL begin LLVM */
+#ifdef ENABLE_LLVM
+  inform ("%JLLVM does not support aliases yet", decl);
+  return;
+#endif
+  /* APPLE LOCAL end LLVM */

    /* We must force creation of DECL_RTL for debug info generation, even though
       we don't use it here.  */


-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Chris Lattner wrote:
> On Thu, 16 Mar 2006, Vladimir Prus wrote:
>> Ah, hell, as soon as I've send this email I've updated from CVS
to find
>> that the issue was fixed by Jim several hours after I reported the
crash,
>> by making MachineDebugInfo don't check for empty name of type.
> 
> :)
> 
>> Here's what I get now:
>>
>>
/space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h:42:
>> internal compiler error: in make_decl_rtl, at varasm.c:1018
>> (gdb) where
>> Preprocessed source goes by private email.
> 
> Great, thanks for the info.  Please try this patch:
This gets me further. After a bunch of "LLVM does not support aliases
yet"
messsages I get this:

  checking for exception model to use... configure: error: unable to detect
  exception model

when building libobjc. When I configure with --enable-languages=c,c++, this
error is gone, so I don't care about at all.

When I run 'make install' ( even when objc is not enabled), I get this:

  make[1]: Entering directory  
  `/space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libobjc'
  make[1]: *** No rule to make target `install'.  Stop.

but again, I don't care about libobjc. When building a trivial program

  #include <iostream>

  int main()
  {
      std::cout << "hi\n";
      return 0;
  }

I get this:

$ llvm-g++ a.cpp
/space/p2/ghost/build/llvm-frontend/install/lib/gcc/i686-pc-linux-gnu/4.0.1/../../../libstdc++.so:undefined
reference to `A_::LTHUNK8'
/space/p2/ghost/build/llvm-frontend/install/lib/gcc/i686-pc-linux-gnu/4.0.1/../../../libstdc++.so:undefined
reference to `A_::LTHUNK11'
........
/space/p2/ghost/build/llvm-frontend/install/lib/gcc/i686-pc-linux-gnu/4.0.1/../../../libstdc++.so:undefined
reference to `std::basic_istream<char,
std::char_traits<char>
>::ignore(int)'
The c version of the same, with printf, links and works correctly.

I'm not very concerned about this error for now, but if you have a new
version for me to test, just say.

Finally, will it be possible to provide an updated snapshot of the frontend,
so that I don't have to apply several patches to get it building?

Thanks for the help,
Volodya

On Fri, 17 Mar 2006, Vladimir Prus wrote:
> Finally, will it be possible to provide an updated snapshot of the
frontend,
> so that I don't have to apply several patches to get it building?
Sorry for the delay, yes, here you go:

http://nondot.org/sabre/2006-03-23-llvm-gcc-4.tar.gz

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/