Paul Melis
2009-Aug-31 13:48 UTC
[LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)
Paul Melis wrote:> Jim Grosbach wrote: >> >> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >> >>> Hello, >>> >>> Bill Wendling wrote: >>>> Before we had buildbots, a random patch would break the system. It >>>> would sometimes take a whole day to determine which patch broke it. >>> I see the buildbots are currently showing no problem on 32-bit linux >>> but >>> I get the following build error with TOT (out-of-source autoconf >>> build): >>> >>> [...] >>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools' >>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime' >>> make[2]: Entering directory >>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for >>> Release build (bytecode) >>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as: >>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>> BasicBlockTracing.ll:1:2: >>> error: expected top-level entity >>> .file "BasicBlockTracing.c" >>> ^ >>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode >>> signature >>> make[2]: *** >>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>> BasicBlockTracing.bc] >>> Error 1 >>> make[2]: Leaving directory >>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>> make[1]: *** [libprofile/.makeall] Error 2 >>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime' >>> make: *** [all] Error 1 >>> >>> It seems BasicBlockTracing.ll contains assembly instead of LLVM IR. >>> >>> >>> Also, llvm-gcc also doesn't build for me. Here the error is related to >>> exception handling: >>> >>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/ >>> libdecnumber' >>> make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>> /home/melis/local/bin/gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings >>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long >>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition >>> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. >>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/. >>> -I../../llvm-gcc-svn/gcc/../include >>> -I../../llvm-gcc-svn/gcc/../libcpp/include >>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber >>> gtype-desc.c -o gtype-desc.o >>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not >>> in a >>> function) >>> make[3]: *** [gtype-desc.o] Error 1 >>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>> make[2]: *** [all-stage1-gcc] Error 2 >>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>> make[1]: *** [stage1-bubble] Error 2 >>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>> make: *** [all] Error 2 >>> >>> Is there something suddenly wrong with my system (which hasn't changed >>> in any way)? I used to be able to build LLVM(GCC) without problems a >>> few >>> weeks ago... >>> >> >> SJLJ exception handling is only implemented on ARM Darwin. It looks >> like your target is pulling in bits of that? > > Well, I don't know what changed to make this suddenly happen. FYI, here is > the configure line I have been using for quite some time: > > ../llvm-gcc-svn/configure \ > --prefix=/home/melis/llvm \ > --program-prefix=llvm- \ > --with-llvm=/home/melis/c/llvm-svn \ > --enable-languages=c,c++ \ > --target=i686-pc-linux-gnu \ > --with-tune=generic \ > --with-arch=pentium4It seems my installed version of llvm-gcc had lost its ability to generate LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that case). That caused LLVM itself not to build, as the stuff in runtime/ picked up the flaky llvm-gcc. Cleaning out my LLVM install and completely rebuilding from scratch fixed the LLVM build. However, llvm-gcc still has the SJLJ error. Paul
Jim Grosbach
2009-Aug-31 16:14 UTC
[LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)
On Aug 31, 2009, at 6:48 AM, Paul Melis wrote:> Paul Melis wrote: >> Jim Grosbach wrote: >>> >>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >>> >>>> Hello, >>>> >>>> Bill Wendling wrote: >>>>> Before we had buildbots, a random patch would break the system. It >>>>> would sometimes take a whole day to determine which patch broke >>>>> it. >>>> I see the buildbots are currently showing no problem on 32-bit >>>> linux >>>> but >>>> I get the following build error with TOT (out-of-source autoconf >>>> build): >>>> >>>> [...] >>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools' >>>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/ >>>> runtime' >>>> make[2]: Entering directory >>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for >>>> Release build (bytecode) >>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as: >>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>> BasicBlockTracing.ll:1:2: >>>> error: expected top-level entity >>>> .file "BasicBlockTracing.c" >>>> ^ >>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode >>>> signature >>>> make[2]: *** >>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>> BasicBlockTracing.bc] >>>> Error 1 >>>> make[2]: Leaving directory >>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>> make[1]: *** [libprofile/.makeall] Error 2 >>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime' >>>> make: *** [all] Error 1 >>>> >>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM IR. >>>> >>>> >>>> Also, llvm-gcc also doesn't build for me. Here the error is >>>> related to >>>> exception handling: >>>> >>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/ >>>> libdecnumber' >>>> make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>> /home/melis/local/bin/gcc -c -g -DIN_GCC -W -Wall -Wwrite- >>>> strings >>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long >>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition >>>> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. >>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/. >>>> -I../../llvm-gcc-svn/gcc/../include >>>> -I../../llvm-gcc-svn/gcc/../libcpp/include >>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber >>>> gtype-desc.c -o gtype-desc.o >>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not >>>> in a >>>> function) >>>> make[3]: *** [gtype-desc.o] Error 1 >>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>> make[2]: *** [all-stage1-gcc] Error 2 >>>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>> make[1]: *** [stage1-bubble] Error 2 >>>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>> make: *** [all] Error 2 >>>> >>>> Is there something suddenly wrong with my system (which hasn't >>>> changed >>>> in any way)? I used to be able to build LLVM(GCC) without >>>> problems a >>>> few >>>> weeks ago... >>>> >>> >>> SJLJ exception handling is only implemented on ARM Darwin. It looks >>> like your target is pulling in bits of that? >> >> Well, I don't know what changed to make this suddenly happen. FYI, >> here is >> the configure line I have been using for quite some time: >> >> ../llvm-gcc-svn/configure \ >> --prefix=/home/melis/llvm \ >> --program-prefix=llvm- \ >> --with-llvm=/home/melis/c/llvm-svn \ >> --enable-languages=c,c++ \ >> --target=i686-pc-linux-gnu \ >> --with-tune=generic \ >> --with-arch=pentium4 > > It seems my installed version of llvm-gcc had lost its ability to > generate > LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in > that > case). That caused LLVM itself not to build, as the stuff in runtime/ > picked up the flaky llvm-gcc. > > Cleaning out my LLVM install and completely rebuilding from scratch > fixed > the LLVM build. However, llvm-gcc still has the SJLJ error.Please try pulling in the changes from r80588. I suspect that'll take care of your issue. Unfortunately, I can't reproduce the failure here to verify directly. -Jim
On 2009-08-31 19:14, Jim Grosbach wrote:> > On Aug 31, 2009, at 6:48 AM, Paul Melis wrote: > >> Paul Melis wrote: >>> Jim Grosbach wrote: >>>> >>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >>>> >>>>> Hello, >>>>> >>>>> Bill Wendling wrote: >>>>>> Before we had buildbots, a random patch would break the system. It >>>>>> would sometimes take a whole day to determine which patch broke it. >>>>> I see the buildbots are currently showing no problem on 32-bit linux >>>>> but >>>>> I get the following build error with TOT (out-of-source autoconf >>>>> build): >>>>> >>>>> [...] >>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools' >>>>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime' >>>>> make[2]: Entering directory >>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for >>>>> Release build (bytecode) >>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as: >>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>>> BasicBlockTracing.ll:1:2: >>>>> error: expected top-level entity >>>>> .file "BasicBlockTracing.c" >>>>> ^ >>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode >>>>> signature >>>>> make[2]: *** >>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>>> BasicBlockTracing.bc] >>>>> Error 1 >>>>> make[2]: Leaving directory >>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>>> make[1]: *** [libprofile/.makeall] Error 2 >>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime' >>>>> make: *** [all] Error 1 >>>>> >>>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM IR. >>>>> >>>>> >>>>> Also, llvm-gcc also doesn't build for me. Here the error is >>>>> related to >>>>> exception handling: >>>>> >>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/ >>>>> libdecnumber' >>>>> make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>>> /home/melis/local/bin/gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings >>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long >>>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition >>>>> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. >>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/. >>>>> -I../../llvm-gcc-svn/gcc/../include >>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include >>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber >>>>> gtype-desc.c -o gtype-desc.o >>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not >>>>> in a >>>>> function) >>>>> make[3]: *** [gtype-desc.o] Error 1 >>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>>> make[2]: *** [all-stage1-gcc] Error 2 >>>>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>>> make[1]: *** [stage1-bubble] Error 2 >>>>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>>> make: *** [all] Error 2 >>>>> >>>>> Is there something suddenly wrong with my system (which hasn't >>>>> changed >>>>> in any way)? I used to be able to build LLVM(GCC) without problems a >>>>> few >>>>> weeks ago... >>>>> >>>> >>>> SJLJ exception handling is only implemented on ARM Darwin. It looks >>>> like your target is pulling in bits of that? >>> >>> Well, I don't know what changed to make this suddenly happen. FYI, >>> here is >>> the configure line I have been using for quite some time: >>> >>> ../llvm-gcc-svn/configure \ >>> --prefix=/home/melis/llvm \ >>> --program-prefix=llvm- \ >>> --with-llvm=/home/melis/c/llvm-svn \ >>> --enable-languages=c,c++ \ >>> --target=i686-pc-linux-gnu \ >>> --with-tune=generic \ >>> --with-arch=pentium4 >> >> It seems my installed version of llvm-gcc had lost its ability to >> generate >> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that >> case). That caused LLVM itself not to build, as the stuff in runtime/ >> picked up the flaky llvm-gcc. >> >> Cleaning out my LLVM install and completely rebuilding from scratch >> fixed >> the LLVM build. However, llvm-gcc still has the SJLJ error. > > Please try pulling in the changes from r80588. I suspect that'll take > care of your issue. Unfortunately, I can't reproduce the failure here > to verify directly.It fixes it for me: with that patch I can bootstrap llvm2.6 now. I think it should be pulled into the 2.6 branch. Best regards, --Edwin
Jim Grosbach wrote:> > On Aug 31, 2009, at 6:48 AM, Paul Melis wrote: > >> Paul Melis wrote: >>> Jim Grosbach wrote: >>>> >>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >>>> >>>>> Hello, >>>>> >>>>> Bill Wendling wrote: >>>>>> Before we had buildbots, a random patch would break the system. It >>>>>> would sometimes take a whole day to determine which patch broke it. >>>>> I see the buildbots are currently showing no problem on 32-bit linux >>>>> but >>>>> I get the following build error with TOT (out-of-source autoconf >>>>> build): >>>>> >>>>> [...] >>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools' >>>>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime' >>>>> make[2]: Entering directory >>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for >>>>> Release build (bytecode) >>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as: >>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>>> BasicBlockTracing.ll:1:2: >>>>> error: expected top-level entity >>>>> .file "BasicBlockTracing.c" >>>>> ^ >>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode >>>>> signature >>>>> make[2]: *** >>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>>> BasicBlockTracing.bc] >>>>> Error 1 >>>>> make[2]: Leaving directory >>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>>> make[1]: *** [libprofile/.makeall] Error 2 >>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime' >>>>> make: *** [all] Error 1 >>>>> >>>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM IR. >>>>> >>>>> >>>>> Also, llvm-gcc also doesn't build for me. Here the error is >>>>> related to >>>>> exception handling: >>>>> >>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/ >>>>> libdecnumber' >>>>> make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>>> /home/melis/local/bin/gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings >>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long >>>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition >>>>> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. >>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/. >>>>> -I../../llvm-gcc-svn/gcc/../include >>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include >>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber >>>>> gtype-desc.c -o gtype-desc.o >>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not >>>>> in a >>>>> function) >>>>> make[3]: *** [gtype-desc.o] Error 1 >>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>>> make[2]: *** [all-stage1-gcc] Error 2 >>>>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>>> make[1]: *** [stage1-bubble] Error 2 >>>>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>>> make: *** [all] Error 2 >>>>> >>>>> Is there something suddenly wrong with my system (which hasn't >>>>> changed >>>>> in any way)? I used to be able to build LLVM(GCC) without problems a >>>>> few >>>>> weeks ago... >>>>> >>>> >>>> SJLJ exception handling is only implemented on ARM Darwin. It looks >>>> like your target is pulling in bits of that? >>> >>> Well, I don't know what changed to make this suddenly happen. FYI, >>> here is >>> the configure line I have been using for quite some time: >>> >>> ../llvm-gcc-svn/configure \ >>> --prefix=/home/melis/llvm \ >>> --program-prefix=llvm- \ >>> --with-llvm=/home/melis/c/llvm-svn \ >>> --enable-languages=c,c++ \ >>> --target=i686-pc-linux-gnu \ >>> --with-tune=generic \ >>> --with-arch=pentium4 >> >> It seems my installed version of llvm-gcc had lost its ability to >> generate >> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that >> case). That caused LLVM itself not to build, as the stuff in runtime/ >> picked up the flaky llvm-gcc. >> >> Cleaning out my LLVM install and completely rebuilding from scratch >> fixed >> the LLVM build. However, llvm-gcc still has the SJLJ error. > > Please try pulling in the changes from r80588. I suspect that'll take > care of your issue. Unfortunately, I can't reproduce the failure here > to verify directly.Well, that seems to have fixed it with TOT, thanks! Paul
Paul Melis wrote:> Paul Melis wrote: > >> Jim Grosbach wrote: >> >>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >>> >>> >>>> Hello, >>>> >>>> Bill Wendling wrote: >>>> >>>>> Before we had buildbots, a random patch would break the system. It >>>>> would sometimes take a whole day to determine which patch broke it. >>>>> >>>> I see the buildbots are currently showing no problem on 32-bit linux >>>> but >>>> I get the following build error with TOT (out-of-source autoconf >>>> build): >>>> >>>> [...] >>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools' >>>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime' >>>> make[2]: Entering directory >>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for >>>> Release build (bytecode) >>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as: >>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>> BasicBlockTracing.ll:1:2: >>>> error: expected top-level entity >>>> .file "BasicBlockTracing.c" >>>> ^ >>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode >>>> signature >>>> make[2]: *** >>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>> BasicBlockTracing.bc] >>>> Error 1 >>>> make[2]: Leaving directory >>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>> make[1]: *** [libprofile/.makeall] Error 2 >>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime' >>>> make: *** [all] Error 1 >>>> >>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM IR. >>>> >>>> >>>> Also, llvm-gcc also doesn't build for me. Here the error is related to >>>> exception handling: >>>> >>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/ >>>> libdecnumber' >>>> make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>> /home/melis/local/bin/gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings >>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long >>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition >>>> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. >>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/. >>>> -I../../llvm-gcc-svn/gcc/../include >>>> -I../../llvm-gcc-svn/gcc/../libcpp/include >>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber >>>> gtype-desc.c -o gtype-desc.o >>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not >>>> in a >>>> function) >>>> make[3]: *** [gtype-desc.o] Error 1 >>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>> make[2]: *** [all-stage1-gcc] Error 2 >>>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>> make[1]: *** [stage1-bubble] Error 2 >>>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>> make: *** [all] Error 2 >>>> >>>> Is there something suddenly wrong with my system (which hasn't changed >>>> in any way)? I used to be able to build LLVM(GCC) without problems a >>>> few >>>> weeks ago... >>>> >>>> >>> SJLJ exception handling is only implemented on ARM Darwin. It looks >>> like your target is pulling in bits of that? >>> >> Well, I don't know what changed to make this suddenly happen. FYI, here is >> the configure line I have been using for quite some time: >> >> ../llvm-gcc-svn/configure \ >> --prefix=/home/melis/llvm \ >> --program-prefix=llvm- \ >> --with-llvm=/home/melis/c/llvm-svn \ >> --enable-languages=c,c++ \ >> --target=i686-pc-linux-gnu \ >> --with-tune=generic \ >> --with-arch=pentium4 >> > > It seems my installed version of llvm-gcc had lost its ability to generate > LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that > case). That caused LLVM itself not to build, as the stuff in runtime/ > picked up the flaky llvm-gcc. >After rebuilding LLVM and llvm-gcc a couple of times now (after rm -rf *-ing the build directories and reconfiguring) I keep having the problem that -S -emit-llvm does not produce LLVM IR, e.g. 22:11|melis at juggle2:~> llvm-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../llvm-gcc-svn/configure --prefix=/home/melis/llvm --program-prefix=llvm- --with-llvm=/home/melis/llvm --enable-languages=c,c++ --target=i686-pc-linux-gnu --with-tune=generic --with-arch=pentium4 : (reconfigured) ../llvm-gcc-svn/configure --prefix=/home/melis/llvm --program-prefix=llvm- --with-llvm=/home/melis/llvm --enable-languages=c,c++ --target=i686-pc-linux-gnu --with-tune=generic --with-arch=pentium4 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5649) 22:11|melis at juggle2:~> cat doh.c #include <stdio.h> int main() { printf("Doh!\n"); } 22:11|melis at juggle2:~> llvm-gcc -S -emit-llvm doh.c 22:11|melis at juggle2:~> ls -l doh.* -rw-r--r-- 1 melis melis 56 Aug 31 22:10 doh.c -rw-r--r-- 1 melis melis 310 Aug 31 22:11 doh.s 22:11|melis at juggle2:~> cat doh.s .file "doh.c" .section .rodata .LC0: .string "Doh!" .text .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $24, %esp movl $.LC0, (%esp) call puts leave ret .size main, .-main .ident "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5649)" .section .note.GNU-stack,"", at progbits I figured perhaps the --with-llvm value I used was wrong (should it be llvm build-dir or final installation dir?), but after trying different values it still makes no difference. What would cause llvm-gcc to loose the capability of writing out LLVM IR? Thanks, Paul
On Aug 31, 2009, at 1:43 PM, Paul Melis wrote:> Paul Melis wrote: >> Paul Melis wrote: >> >>> Jim Grosbach wrote: >>> >>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> Bill Wendling wrote: >>>>> >>>>>> Before we had buildbots, a random patch would break the system. >>>>>> It >>>>>> would sometimes take a whole day to determine which patch broke >>>>>> it. >>>>>> >>>>> I see the buildbots are currently showing no problem on 32-bit >>>>> linux >>>>> but >>>>> I get the following build error with TOT (out-of-source autoconf >>>>> build): >>>>> >>>>> [...] >>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools' >>>>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/ >>>>> runtime' >>>>> make[2]: Entering directory >>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc >>>>> for >>>>> Release build (bytecode) >>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as: >>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>>> BasicBlockTracing.ll:1:2: >>>>> error: expected top-level entity >>>>> .file "BasicBlockTracing.c" >>>>> ^ >>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode >>>>> signature >>>>> make[2]: *** >>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/ >>>>> BasicBlockTracing.bc] >>>>> Error 1 >>>>> make[2]: Leaving directory >>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile' >>>>> make[1]: *** [libprofile/.makeall] Error 2 >>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/ >>>>> runtime' >>>>> make: *** [all] Error 1 >>>>> >>>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM >>>>> IR. >>>>> >>>>> >>>>> Also, llvm-gcc also doesn't build for me. Here the error is >>>>> related to >>>>> exception handling: >>>>> >>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/ >>>>> libdecnumber' >>>>> make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>>> /home/melis/local/bin/gcc -c -g -DIN_GCC -W -Wall -Wwrite- >>>>> strings >>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long >>>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style- >>>>> definition >>>>> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. >>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/. >>>>> -I../../llvm-gcc-svn/gcc/../include >>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include >>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber >>>>> gtype-desc.c -o gtype-desc.o >>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not >>>>> in a >>>>> function) >>>>> make[3]: *** [gtype-desc.o] Error 1 >>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc' >>>>> make[2]: *** [all-stage1-gcc] Error 2 >>>>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>>> make[1]: *** [stage1-bubble] Error 2 >>>>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build' >>>>> make: *** [all] Error 2 >>>>> >>>>> Is there something suddenly wrong with my system (which hasn't >>>>> changed >>>>> in any way)? I used to be able to build LLVM(GCC) without >>>>> problems a >>>>> few >>>>> weeks ago... >>>>> >>>>> >>>> SJLJ exception handling is only implemented on ARM Darwin. It looks >>>> like your target is pulling in bits of that? >>>> >>> Well, I don't know what changed to make this suddenly happen. FYI, >>> here is >>> the configure line I have been using for quite some time: >>> >>> ../llvm-gcc-svn/configure \ >>> --prefix=/home/melis/llvm \ >>> --program-prefix=llvm- \ >>> --with-llvm=/home/melis/c/llvm-svn \ >>> --enable-languages=c,c++ \ >>> --target=i686-pc-linux-gnu \ >>> --with-tune=generic \ >>> --with-arch=pentium4 >>> >> >> It seems my installed version of llvm-gcc had lost its ability to >> generate >> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in >> that >> case). That caused LLVM itself not to build, as the stuff in runtime/ >> picked up the flaky llvm-gcc. >> > After rebuilding LLVM and llvm-gcc a couple of times now (after rm -rf > *-ing the build directories and reconfiguring) I keep having the > problem > that -S -emit-llvm does not produce LLVM IR, e.g. > > 22:11|melis at juggle2:~> llvm-gcc -v > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ../llvm-gcc-svn/configure --prefix=/home/melis/llvm > --program-prefix=llvm- --with-llvm=/home/melis/llvm > --enable-languages=c,c++ --target=i686-pc-linux-gnu --with- > tune=generic > --with-arch=pentium4 : (reconfigured) ../llvm-gcc-svn/configure > --prefix=/home/melis/llvm --program-prefix=llvm- > --with-llvm=/home/melis/llvm --enable-languages=c,c++ > --target=i686-pc-linux-gnu --with-tune=generic --with-arch=pentium4 > Thread model: posix > gcc version 4.2.1 (Based on Apple Inc. build 5649) > 22:11|melis at juggle2:~> cat doh.c > #include <stdio.h> > int main() > { > printf("Doh!\n"); > } > 22:11|melis at juggle2:~> llvm-gcc -S -emit-llvm doh.c > 22:11|melis at juggle2:~> ls -l doh.* > -rw-r--r-- 1 melis melis 56 Aug 31 22:10 doh.c > -rw-r--r-- 1 melis melis 310 Aug 31 22:11 doh.s > 22:11|melis at juggle2:~> cat doh.s > .file "doh.c" > .section .rodata > .LC0: > .string "Doh!" > .text > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $24, %esp > movl $.LC0, (%esp) > call puts > leave > ret > .size main, .-main > .ident "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5649)" > .section .note.GNU-stack,"", at progbits > > I figured perhaps the --with-llvm value I used was wrong (should it be > llvm build-dir or final installation dir?), but after trying different > values it still makes no difference. What would cause llvm-gcc to > loose > the capability of writing out LLVM IR? >Does --enable-llvm=<path> instead of --with-llvm=<path> yield the same results? -Jim
Hello, Paul> >> ../llvm-gcc-svn/configure \ > >> --prefix=/home/melis/llvm \ > >> --program-prefix=llvm- \ > >> --with-llvm=/home/melis/c/llvm-svn \You need to use --enable-llvm, not --with-llvm> gcc version 4.2.1 (Based on Apple Inc. build 5649)As you can see - this is not llvm-enabled gcc -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
Hi Paul,> I figured perhaps the --with-llvm value I used was wrong (should it be > llvm build-dir or final installation dir?), but after trying different > values it still makes no difference. What would cause llvm-gcc to loose > the capability of writing out LLVM IR?maybe you built an llvm-gcc with LLVM disabled (in which case you get an ordinary Apple GCC, or at least you're supposed to)? Did you specify --enable-llvm when configuring GCC? Ciao, Duncan.
Maybe Matching Threads
- [LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)
- [LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)
- [LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)
- [LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)
- [LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)