On Jan 10, 2008, at 12:52 PM, Thomas Jablin wrote:>>
> 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
BOOTSTRAPshould stop it from trying to bootstrap. However, it's still
likely
to try to build the file that's causing trouble.
>>> 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 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
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>> -
>> Devang
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev