llvm dev - Oct 2007 - [LLVMdev] Can't bootstrap llvm-gcc-4.0 for x84_64

On Wednesday 10 October 2007 17:12, David Greene wrote:
> This particular problem is gone (thanks!) but I'm having other
troubles.
> I'm tracking those down now.
This is the current problem:

[x86_64-off-dbg]: ./xgcc -B./ 
-B/install.official.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/
-isystem
/install.official.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/include
-isystem
/install.official.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-include
-L/tmp/ptmp/dag/build.llvm-gcc-4.0.official.debug/x86_64-unknown-linux-gnu/gcc/../ld
-O2 -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I32 
-I/llvm-project.official/llvm-gcc-4.0/trunk/gcc 
-I/llvm-project.official/llvm-gcc-4.0/trunk/gcc/32 
-I/llvm-project.official/llvm-gcc-4.0/trunk/gcc/../include 
-I/llvm-project.official/llvm-gcc-4.0/trunk/gcc/../libcpp/include  
-I/llvm-project.official/llvm/trunk/include 
-I/ptmp/dag/build.llvm.official.debug/x86_64-unknown-linux-gnu/include -m32 
-g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions 
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer 
-fno-asynchronous-unwind-tables \
[x86_64-off-dbg]: 	   
-c /llvm-project.official/llvm-gcc-4.0/trunk/gcc/crtstuff.c -DCRT_BEGIN \
[x86_64-off-dbg]: 	  -o 32/crtbegin.o
[x86_64-off-dbg]: Warning: Generation of 64-bit code for a 32-bit processor 
requested.
[x86_64-off-dbg]: Warning: 64-bit processors all have at least SSE2.
[x86_64-off-dbg]: 
cc1: /llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp:82: const 
llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!
(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum 
tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t,
(tcc_type),
"/llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp",
82, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64
((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum 
tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t,
(tcc_type),
"/llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp",
82, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ 
({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) 
(__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, 
(tcc_type),
"/llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp",
82, __FUNCTION__); __t; })->type.size), true) == 
getTargetData().getABITypeSizeInBits(Ty)) && "LLVM type size
doesn't match
GCC type size!"' failed.
[x86_64-off-dbg]: /llvm-project.official/llvm-gcc-4.0/trunk/gcc/crtstuff.c:194: 
internal compiler error: Aborted

Unfortunately, I don't know enough about gcc internals to really dig into 
this.  If someone immediately knows what this is, then great.  Otherwise
I may have to start reading info files.  :)

The warning about 64-bit code on a 32-bit target is worrisome.  Is that
supposed to happen?

                                                        -Dave

On Oct 10, 2007, at 4:28 PM, David Greene wrote:
> On Wednesday 10 October 2007 17:12, David Greene wrote:
>
>> This particular problem is gone (thanks!) but I'm having other  
>> troubles.
>> I'm tracking those down now.
>
> This is the current problem:
>
> The warning about 64-bit code on a 32-bit target is worrisome.  Is  
> that
> supposed to happen?
Since you're passing -m32 which asks for 32-bit code, no, it's not.

If you cut and paste that command line with -save-temps -v , you'll  
see the
arguments being passed to cc1 (the actual compiler).  If you debug that
and stop at the crash site, you can dump gcc "tree" objects with
"print debug_tree(p)".  With luck you can relate that back to the  
source,
or I may be able to help.

Hi David,
> "LLVM type size doesn't match GCC type size!"' failed.
this assertion checks that gcc types are converted into
LLVM types of the same size.  Try running cc1 in gdb.
When you hit the assertion, go up a few stack frames
until you get to ConvertType.  Do
	call debug_tree(type)
That will tell you what the gcc type was.  From that
and the LLVM type it should be clear what the ultimate
cause of the problem was.

Ciao,

Duncan.

On Thursday 11 October 2007 02:39, Duncan Sands wrote:
> Hi David,
>
> > "LLVM type size doesn't match GCC type size!"'
failed.
>
> this assertion checks that gcc types are converted into
> LLVM types of the same size.  Try running cc1 in gdb.
> When you hit the assertion, go up a few stack frames
> until you get to ConvertType.  Do
> 	call debug_tree(type)
> That will tell you what the gcc type was.  From that
> and the LLVM type it should be clear what the ultimate
> cause of the problem was.
Ok, I think this must be related to the warning about 64-bit code.
debug_type reveals the gcc type to be a function pointer of size
32, which would indicate 32-bit code.  The llvm type is PointerTyID
of size 64, indicating 64-bit code.

This happens at line 796 of llvm-types.cpp:

      if (Ty->getTypeID() == Type::VoidTyID) 
        Ty = Type::Int8Ty;  // void* -> sbyte*
      return TypeDB.setType(type, PointerType::get(Ty));

Somehow PointerType::get is returning a 64-bit pointer even though
-m32 was passed to llvm-gcc.

I'll see if I can figure out where the 64-bit code warning is emitted and
what triggers it.

                                                   -Dave