LLVM Build Problems on Itanium

Hi,

I am having some difficulties building llvm on Itanium. My procedure for building LLVM is:

cd /liberty/llvm.ia64/llvm-2.1
./configure
make ENABLE_OPTIZED=1
cd /liberty/llvm.ia64/obj
/liberty/llvm.ia64/llvm-gcc4.2-2.1.source/configure --prefix=/liberty/llvm.ia64/install --enable-llvm=/liberty/llvm.ia64/llvm-2.1/ --enable-languages=c,c++ --disable-shared

The build of llvm seems to succeed, but llvm-gcc dies with the following messages:

gcc -Wall -c -DUSE_LIBUNWIND_EXCEPTIONS -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc -I/liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc/. -I/liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc/../include -I/liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc/../libcpp/include -I/liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc/../libdecnumber -I../libdecnumber -I/liberty/llvm.ia64/llvm-2.1/include -I/liberty/llvm.ia64/llvm-2.1//include -DENABLE_LLVM -I/liberty/llvm.ia64/llvm-2.1/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS /liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc/dbxout.c -o dbxout.o
In file included from /liberty/llvm.ia64/llvm-gcc4.2-2.1.source/gcc/dbxout.c:4365:
./gt-dbxout.h: In function ‘gt_ggc_ma_type_queue’:
./gt-dbxout.h:83: error: ‘type_queue’ undeclared (first use in this function)
./gt-dbxout.h:83: error: (Each undeclared identifier is reported only once
./gt-dbxout.h:83: error: for each function it appears in.)
./gt-dbxout.h:85: error: ‘type_queue_index’ undeclared (first use in this function)
./gt-dbxout.h: In function ‘gt_pch_pa_type_queue’:
./gt-dbxout.h:99: error: ‘type_queue’ undeclared (first use in this function)
./gt-dbxout.h:101: error: ‘type_queue_index’ undeclared (first use in this function)
./gt-dbxout.h: In function ‘gt_pch_na_type_queue’:
./gt-dbxout.h:114: error: ‘type_queue’ undeclared (first use in this function)
./gt-dbxout.h:116: error: ‘type_queue_index’ undeclared (first use in this function)
./gt-dbxout.h: At top level:
./gt-dbxout.h:205: error: ‘type_queue’ undeclared here (not in a function)
./gt-dbxout.h:250: error: ‘type_queue_size’ undeclared here (not in a function)
./gt-dbxout.h:250: error: initializer element is not constant
./gt-dbxout.h:250: error: (near initialization for ‘gt_pch_rs_gt_dbxout_h[0].base’)
./gt-dbxout.h:250: error: initializer element is not constant
./gt-dbxout.h:250: error: (near initialization for ‘gt_pch_rs_gt_dbxout_h[0].stride’)
./gt-dbxout.h:251: error: ‘type_queue_index’ undeclared here (not in a function)
./gt-dbxout.h:251: error: initializer element is not constant
./gt-dbxout.h:251: error: (near initialization for ‘gt_pch_rs_gt_dbxout_h[1].base’)
./gt-dbxout.h:251: error: initializer element is not constant
./gt-dbxout.h:251: error: (near initialization for ‘gt_pch_rs_gt_dbxout_h[1].stride’)
make[3]: *** [dbxout.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

My system is CentOS 4.5, which includes gcc 3.4.6, flex 2.5.4, m4 1.4.1, and bison 1.875c. I have attempted to build llvm-gcc with a self-built copies of gcc 4.2.1 and bison 2.3 which yielded similar error messages. I have diff'd the Itanium generated copy of gt-dbxout.h against the gt-dbxout.h from a successful x86-64 build and found no changes. Any help would be greatly appreciated.

Tom

Hi,

I've figured out a little more. #if defined DBX_DEBUGGING_INFO || XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, neither is defined on Intanium. In gt-dbxout.h type_queue's uses are unguarded and thus are undefined on Itanium. When I compared llvm-gcc's gt-dbxout.h with FSF gcc's, I found that type_queue was never used in FSF gcc's version. Does anyone know what DBX_DEBUGGING_INFO and XCOFF_DEBUGGING_INFO signify? I know that gt-dbxout.h is machine generated. Does anyone know where and how this machine generation occurs? Thanks.
Tom

Thomas Jablin wrote:

Hi,

I've figured out a little more. #if defined DBX_DEBUGGING_INFO ||
XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however,
neither is defined on Intanium. In gt-dbxout.h type_queue's uses are
unguarded and thus are undefined on Itanium. When I compared llvm-gcc's
gt-dbxout.h with FSF gcc's, I found that type_queue was never used in
FSF gcc's version. Does anyone know what DBX_DEBUGGING_INFO and
XCOFF_DEBUGGING_INFO signify?

DBX_DEBUGGING_INFO enables "stabs" debugging format. dbxout.c is responsible to generate debugging information in this format and I beleive type_queue is defined in dbxout.c

If your platform is not using stabs debugging format (nowadays most of the platforms use DWARF format) then it won't define DBX_DEBUGGING_INFO.

Hi,

I've figured out a little more. #if defined DBX_DEBUGGING_INFO ||
XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however,
neither is defined on Intanium. In gt-dbxout.h type_queue's uses are
unguarded and thus are undefined on Itanium. When I compared llvm-gcc's
gt-dbxout.h with FSF gcc's, I found that type_queue was never used in
FSF gcc's version. Does anyone know what DBX_DEBUGGING_INFO and
XCOFF_DEBUGGING_INFO signify? I know that gt-dbxout.h is machine
generated. Does anyone know where and how this machine generation
occurs? Thanks.
Tom

I believe the code that does it is in gengtype* . Not sure what the executable
is called.

This is almost certainly a configuration issue.

Devang Patel wrote:

Hi,

I've figured out a little more. #if defined DBX_DEBUGGING_INFO ||
XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however,
neither is defined on Intanium. In gt-dbxout.h type_queue's uses are
unguarded and thus are undefined on Itanium. When I compared llvm- gcc's
gt-dbxout.h with FSF gcc's, I found that type_queue was never used in
FSF gcc's version. Does anyone know what DBX_DEBUGGING_INFO and
XCOFF_DEBUGGING_INFO signify?
    
DBX_DEBUGGING_INFO enables "stabs" debugging format. dbxout.c is responsible to generate debugging information in this format and I beleive type_queue is defined in dbxout.c

If your platform is not using stabs debugging format (nowadays most of the platforms use DWARF format) then it won't define DBX_DEBUGGING_INFO.

Based on your response I've removed the #undef DBX_DEBUGGING_INFO in gcc/config/ia64/sysv4.h. I don't need stabs debugging so if it is broken in my final build, I won't care. After doing so, my llvm-gcc build runs for a much longer time before finally dying while running xgcc. Here is the final output:

/liberty/llvm.ia64/obj/./gcc/xgcc -B/liberty/llvm.ia64/obj/./gcc/ -B/liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/bin/ -B/liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/lib/ -isystem /liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/include -isystem /liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -DUSE_GAS_SYMVER -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -c -o crtfastmath.o \
../../llvm-gcc4.2-2.1.source/gcc/config/ia64/crtfastmath.c
cc1: SelectionDAGISel.cpp:3695: void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallInst&): Assertion `!OpInfo.AssignedRegs.Regs.empty() && "Couldn't allocate input reg!"' failed.
../../llvm-gcc4.2-2.1.source/gcc/config/ia64/crtfastmath.c:37: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[3]: *** [crtfastmath.o] Error 1
make[3]: Leaving directory `/liberty/llvm.ia64/obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/liberty/llvm.ia64/obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/liberty/llvm.ia64/obj'
make: *** [all] Error 2

I think this may be an LLVM bug or unsupported IA64-ism. crtfastmath.c consists of a single function with only one line of inline assembly. Is this an easy fix, and if so could someone point me in the general direction? Alternatively, is it possible to skip the xgcc bootstrap and compile llvm-gcc directly? Thanks.
Tom

Based on your response I've removed the #undef DBX_DEBUGGING_INFO in
gcc/config/ia64/sysv4.h. I don't need stabs debugging so if it is broken
in my final build, I won't care. After doing so, my llvm-gcc build runs
for a much longer time before finally dying while running xgcc. Here is
the final output:

/liberty/llvm.ia64/obj/./gcc/xgcc -B/liberty/llvm.ia64/obj/./gcc/
-B/liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/bin/
-B/liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/lib/ -isystem
/liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/include
-isystem
/liberty/llvm.ia64/obj/../install/ia64-unknown-linux-gnu/sys-include -O2
-O2 -g -O2 -DIN_GCC -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -DUSE_GAS_SYMVER -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -c -o crtfastmath.o \
../../llvm-gcc4.2-2.1.source/gcc/config/ia64/crtfastmath.c
cc1: SelectionDAGISel.cpp:3695: void
llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallInst&): Assertion
`!OpInfo.AssignedRegs.Regs.empty() && "Couldn't allocate input reg!"'
failed.
../../llvm-gcc4.2-2.1.source/gcc/config/ia64/crtfastmath.c:37: internal
compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[3]: *** [crtfastmath.o] Error 1
make[3]: Leaving directory `/liberty/llvm.ia64/obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/liberty/llvm.ia64/obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/liberty/llvm.ia64/obj'
make: *** [all] Error 2

I think this may be an LLVM bug or unsupported IA64-ism. crtfastmath.c
consists of a single function with only one line of inline assembly. Is
this an easy fix, and if so could someone point me in the general
direction? Alternatively, is it possible to skip the xgcc bootstrap and
compile llvm-gcc directly? Thanks.
Tom

That's an LLVM bug. Inline assembly is known to have some problems.
I'm not sure how robust the ia64 implementation is.

Configuring with
BOOTSTRAP=
should stop it from trying to bootstrap. However, it's still likely to try to build the file that's causing trouble.

Dale Johannesen wrote:

That's an LLVM bug. Inline assembly is known to have some problems.
I'm not sure how robust the ia64 implementation is.

Configuring with
BOOTSTRAP=
should stop it from trying to bootstrap. However, it's still likely to try to build the file that's causing trouble.
  

Is there any reason why I can't use xgcc to generate LLVM bitcodes? What are the limitations of xgcc relative to gcc?
Tom

Dale Johannesen wrote:

That's an LLVM bug. Inline assembly is known to have some problems.
I'm not sure how robust the ia64 implementation is.

Configuring with
BOOTSTRAP=
should stop it from trying to bootstrap.

Actually it's --disable-bootstrap on the FSF-style configure, sorry.

However, it's still likely
to try to build the file that's causing trouble.

Is there any reason why I can't use xgcc to generate LLVM bitcodes? What
are the limitations of xgcc relative to gcc?
Tom

That will work, as long as you don't try to use it to link. Its header file search
paths will be different from the installed gcc.