New GCC4-based C/C++/ObjC front-end for LLVM

Project Infrastructure LLVM Dev List Archives
1

Hi Everyone,

I just pushed out the latest version of my new GCC4-based llvm-gcc here:
http://gcc.gnu.org/ml/gcc/2006-01/msg00931.html
This email includes status and instructions for use.

Compared to the old llvm-gcc, this front-end has many advantages: it is far faster, is based on GCC 4.0.1 instead of a GCC 3.4 prerelease snapshot, and it fixes several dozen of the "impossible to fix in the old front-end" bugs revolving around bitfield layout and static initialization global unions (see http://llvm.cs.uiuc.edu/PR498 for examples).

This front-end is different than the old llvm-gcc in several ways: in particular, it defaults to acting like a *normal* compiler. Specifically:

1. "llvm-gcc x.c -S -o x.s" will give you an *unoptimized* *native*
    assembly file, not an unoptimized LLVM .ll file.
2. "llvm-gcc x.c -c -o x.o" will give you an *unoptimized* *native* object
    file, not an *optimized* LLVM .bc file.
3. "llvm-gcc x.c" will give you a native a.out, not a .bc file.
4. -O[123] flags change the output of the compiler, though they are all
    very basic. The new compiler does not yet run all of the optimizations
    the old one did with "-c".
5. The new front-end does not exec gccas/gccld, instead it links to the
    appropriate LLVM libraries.
6. Link-time IPO hasn't been implemented yet.

Finally, note that passing both the new and old front-ends "-S -emit-llvm" will cause them both to behave the same: they both write an LLVM .ll file to the .s file. This allows the testsuite to work with both front-ends.

I would appreciate it if people would try it out and see how it works for them. I'd like to add support for the Alpha, itanium, and sparc backends, but would like the target maintainers to test it for basic functionality. The link above includes instructions to build the new front-end. If you build with --program-prefix=llvm- and configure LLVM with the installed compiler, you can run the llvm-test suite as normal, using the new front-end instead of the old one.

Ideally, I would like to "ship" this front-end along with the current front-end for the next LLVM release (1.7), and then drop the old llvm-gcc for the next one (1.8).

Comments and questions welcome,

-Chris

2

Chris Lattner wrote:

Hi Everyone,

I just pushed out the latest version of my new GCC4-based llvm-gcc here:
Chris Lattner - Updated LLVM+GCC Patch
This email includes status and instructions for use.

The instructions seem to have one path wrong. It says to get:

    svn://gcc.gnu.org/svn/gcc/branches/apple/trunk/gcc, revision 108127.

but the patch won't apply to that directory, because it tries to change
things under libstdc++-v3 and so on. I suppose that

    svn://gcc.gnu.org/svn/gcc/branches/apple/trunk

(without 'gcc' at the end) is right. Not a big issue, but might confuse
casual users.

- Volodya

3

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.

-Chris

4

Chris Lattner wrote:

5

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

6

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

memcpy.patch (3.36 KB)

7

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

8

../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1305: error: parse

error

  before `__attribute__'

Can you send me the preprocessed .i file for this file?

To work around the above error, just remove "ATTRIBUTE_UNUSED" from that line.

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

This is more strange. The code likes this for me:

     for (tree_stmt_iterator I = tsi_start(node); !tsi_end_p(I); tsi_next(&I))
       if (TREE_CODE(tsi_stmt(I)) == LABEL_EXPR)
         SET_DECL_LLVM(TREE_OPERAND(tsi_stmt(I), 0), 0);

Is this what you have? If so, can you send me the preprocessed source file? What host compiler are you using?

-Chris

9

Chris Lattner wrote:

../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1305: error: parse

error

  before `__attribute__'

Can you send me the preprocessed .i file for this file?

Sure, I've sent it by private email (180K is too big for list).

To work around the above error, just remove "ATTRIBUTE_UNUSED" from that
line.

Ok, done.

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

This is more strange. The code likes this for me:

     for (tree_stmt_iterator I = tsi_start(node); !tsi_end_p(I);
     tsi_next(&I))
       if (TREE_CODE(tsi_stmt(I)) == LABEL_EXPR)
         SET_DECL_LLVM(TREE_OPERAND(tsi_stmt(I), 0), 0);

Is this what you have?

Yes, but after removing ATTRIBUTE_UNUSED the second error is gone. <rumbling
about syntax errors recovery quality in gcc.../>

What host compiler are you using?

  gcc version 3.3.5 (Debian 1:3.3.5-13)

Should handle attributes just fine, I think. Ah, I know the problem. The
compile fails with:

    void *data ATTRIBUTE_UNUSED) {

but works with:

    void ATTRIBUTE_UNUSED *data) {

and with:

    ATTRIBUTE_UNUSED void *data) {

IIRC, gcc used to be picky about placements of attributes. Any change you'll
change to any of working syntaxes, or, you 100% portable approach of:

    void* /* data */) {

Thanks,
Volodya

10

Chris Lattner 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

11

Can you send me the preprocessed .i file for this file?

Sure, I've sent it by private email (180K is too big for list).

Thanks.

Is this what you have?

Yes, but after removing ATTRIBUTE_UNUSED the second error is gone. <rumbling
about syntax errors recovery quality in gcc.../>

Okay, that makes much more sense :slight_smile:

IIRC, gcc used to be picky about placements of attributes. Any change you'll
change to any of working syntaxes, or, you 100% portable approach of:

   void* /* data */) {

This is what I did. Thanks! :slight_smile:

-Chris

12

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 :slight_smile:

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

13

Chris Lattner wrote:

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!

Here we go:

/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 -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../../2006-03-14-llvm-gcc-4/gcc -I../../2006-03-14-llvm-gcc-4/gcc/.
-I../../2006-03-14-llvm-gcc-4/gcc/../include
-I../../2006-03-14-llvm-gcc-4/gcc/../libcpp/include
-I/space/p2/ghost/build/llvm-cvs/include -DL_fixunsxfdi
-fvisibility=hidden -DHIDE_EXPORTS
-c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o
cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void
llvm::AllocationInst::setAlignment(unsigned int): Assertion `(Align &
(Align-1)) == 0 && "Alignment is not a power of 2!"' failed.
../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c: In function '__fixunsxfdi':
../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c:1205: internal compiler error:
Aborted
Please submit a full bug report,
with preprocessed source if appropriate.

The preprocessed source will be send by private email.

- Volodya

14

Please give it a try and let me know if it works any better for you!

Here we go:

Wow, you are good at finding problems! Thanks!

-fvisibility=hidden -DHIDE_EXPORTS
-c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o
cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void
llvm::AllocationInst::setAlignment(unsigned int): Assertion `(Align &
(Align-1)) == 0 && "Alignment is not a power of 2!"' failed.
../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c: In function '__fixunsxfdi':
../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c:1205: internal compiler error:
Aborted
Please submit a full bug report,
with preprocessed source if appropriate.

I can't reproduce this on darwin-ppc or darwin-x86, so this is a stab in the dark. Can you try this patch:

15

Hi,

Here is the follow on patch for this problem. Please apply this from the top of the tree and rebuild.

op (2.49 KB)

16

Evan Cheng wrote:

Hi,

Here is the follow on patch for this problem. Please apply this from
the top of the tree and rebuild.

With the patch from Chris and then the patch from you combined, the previous
error disappeared, but I get another error, reduced to this:

./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro
-auxbase-strip libgcc/./_clz.o -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fPIC -fvisibility=hidden -o libgcc2.s
.....
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

And this time the crash does not seem very misterious:

Program received signal SIGSEGV, Segmentation fault.
llvm::PATypeHolder::get (this=0x8) at Type.h:249
249 const Type *getForwardedType() const {

(gdb) where
#0 llvm::PATypeHolder::get (this=0x8) at Type.h:249
#1 0x08514f1f in llvm::PATypeHolder::operator llvm::Type* (this=0x8) at
AbstractTypeUser.h:140
#2 0x08514734 in llvm::Value::getType (this=0x0) at Value.h:76
#3 0x087a8f8a in ConstantStruct (this=0x8b28038, T=0x8b25730,
V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:275
#4 0x087e9058 in llvm::ConstantCreator<llvm::ConstantStruct,
llvm::StructType, std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> > >::create (Ty=0x8b25730, V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:531
#5 0x087e6eaf in (anonymous
namespace)::ValueMap<std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> >, llvm::StructType, llvm::ConstantStruct,

::getOrCreate (this=0x8af8060,

    Ty=0x8b25730, V=@0xbf8adef0)
at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:624
#6 0x087aa821 in llvm::ConstantStruct::get (Ty=0x8b25730, V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:994
#7 0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834,
DD=0x8b54480)
    at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204

The real problem is this:

#7 0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834,
DD=0x8b54480)
    at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204
1204 GV->setInitializer(ConstantStruct::get(Ty, Elements));
(gdb) p Elements[2]
$7 = (class llvm::Constant * const&) @0x8afbcf0: 0x0

This null pointer comes from line 274 of MachineDebugInfo.cpp:

  virtual void Apply(std::string &Field) {
    if (Field.empty()) {
      Elements.push_back(NULL);
    } else {
      Elements.push_back(SR.getString(Field));
    }
  }

Which comes from this:

  void TypeDesc::ApplyToFields(DIVisitor *Visitor) {
    DebugInfoDesc::ApplyToFields(Visitor);
  
    Visitor->Apply(Context);
    Visitor->Apply(Name);

Name is empty. Here's a minimal testcase that reproduces the crash:

   unsigned __clz_tab = {0};

just invoke cc1 as given in the beginning of this email with this text as
input.

The problem is that llvm-debug.cpp:GetNodeName returns "" for the name of
type of "__clz_tab", which is the root cause of the crash. I don't know why
TYPE_NAME returns NULL, but I attach two possible patches.

First one just special cases arrays and integer variables. Again, don't know
why, but TYPE_NAME returns 0 even if 'tree' is a 'unsigned' type.

Second one makes GetNodeName return non-empty string if it fails to
determine the name.

Neither patch is reasonable, but at least we know the problem. Now I get
crash in this (minimal) testcase:

   struct gcov_info
   {
      const char *filename;
   };

   struct gcov_info gcov_list;

This time the crash happens because DerivedTypeDesc corresponding to
   DW_TAG_const_type<
         char*
   >
has no name. What follows from that is already explained above.

So, it looks either the snapshot is not in stable state, or there's
something seriously wrong with type name handling. At this point I gave up
on quickly fixing this, so I've applied the third attached patch to LLVM,
which "fixes" this issue completely.

After that, the frontend itself builds (the gcc directory), and "llvm-g++
-emit-llvm -S some_file.cpp") works. I did not do deep testing.

On the other hand, I still get segfaults when building libstdc++. I'll look
at them as soon as this "type name in debug info" is solved or workarounded
either in LLVM CVS or in your frontend.

Sorry for the long email, this is basically a debugging log :wink:

- Volodya

llvm-debug-patch1.diff (2.07 KB)

llvm-debug-patch2.diff (339 Bytes)

llvm-debug-patch3.diff (623 Bytes)

17

Vladimir Prus wrote:

So, it looks either the snapshot is not in stable state, or there's
something seriously wrong with type name handling. At this point I gave up
on quickly fixing this, so I've applied the third attached patch to LLVM,
which "fixes" this issue completely.

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.

After that, the frontend itself builds (the gcc directory), and "llvm-g++
-emit-llvm -S some_file.cpp") works. I did not do deep testing.

On the other hand, I still get segfaults when building libstdc++. I'll
look at them as soon as this "type name in debug info" is solved or
workarounded either in LLVM CVS or in your frontend.

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
#0 internal_error (gmsgid=0x8a02d8f "make_decl_rtl")
    at ../../2006-03-14-llvm-gcc-4/gcc/diagnostic.c:532
#1 0x082bf22f in fancy_abort (file=0x8a02d8f "make_decl_rtl", line=1018,
    function=0x8a02d8f "make_decl_rtl")
at ../../2006-03-14-llvm-gcc-4/gcc/diagnostic.c:588
#2 0x084c0c5c in make_decl_rtl (decl=0xb7b9d618)
at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:1018
#3 0x084c8207 in assemble_alias (decl=0xb7b9d618, target=0xb698fe00)
    at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:4765
#4 0x084d05e6 in rest_of_decl_compilation (decl=0xb7b9d618, top_level=1,
at_end=0)
    at ../../2006-03-14-llvm-gcc-4/gcc/passes.c:204

Printing decl in frame 2 gives:

(gdb) call debug_tree(decl)
<function_decl 0xb7b9d618
_X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv
    type <function_type 0xb7ab7e88
        type <void_type 0xb7ab5b40 void sizes-gimplified type_6 VOID
            align 8 symtab 146744576 alias set -1
            pointer_to_this <pointer_type 0xb7ab5bb8>>
        type_6 QI
        size <integer_cst 0xb7aa139c constant invariant 8>
        unit size <integer_cst 0xb7aa13b8 constant invariant 1>
        align 8 symtab 0 alias set -1
        arg-types <tree_list 0xb7aa1efc value <void_type 0xb7ab5b40 void>>
        pointer_to_this <pointer_type 0xb7121ca8>>
    public external asm-frame-size 0 no-static-chain decl_2 QI
file /space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h
line 42 context<namespace_decl 0xb720a1e0 __gnu_internal> attributes
<tree_list 0xb7137bd0> initial <error_mark 0xb7aa12d8>
    chain <template_decl 0xb720aac8 __test_type>>

Preprocessed source goes by private email.

- Volodya

18

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.

:slight_smile:

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

19

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

:slight_smile:

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

20

Sorry for the delay, yes, here you go:

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

-Chris