TEST 'LLVM :: DebugInfo/debuglineinfo.test' FAILED $ llvm-rtdyld -printline test/DebugInfo/Inputs/test-inline.o -- Exit Code: 2 Command Output (stderr): -- llvm-rtdyld: include/llvm/Object/ELF.h:78: llvm::object::ELFFile<ELFT>::ELFEntityIterator<EntT>::value_type* llvm::object::ELFFile<ELFT>::ELFEntityIterator<EntT>::operator->() [with EntT = const llvm::object::Elf_Shdr_Impl<llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true> >; ELFT = llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true>; llvm::object::ELFFile<ELFT>::ELFEntityIterator<EntT>::pointer = const llvm::object::Elf_Shdr_Impl<llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true> >*; llvm::object::ELFFile<ELFT>::ELFEntityIterator<EntT>::value_type = const llvm::object::Elf_Shdr_Impl<llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true> >]: Assertion `Current && "Attempted to dereference an invalid iterator!"' failed.
Building LLVM with -O1 or -O2 fixes the problem, so it's something nasty that gcc 4.7.2 is doing on Odroid. If fails in the following code: template <class ELFT> ELFFile<ELFT>::ELFFile(MemoryBuffer *Object, error_code &ec) : Buf(Object), ... dt_soname(0) { const uint64_t FileSize = Buf->getBufferSize(); if (sizeof(Elf_Ehdr) > FileSize) // FIXME: Proper error handling. report_fatal_error("File too short!"); Header = reinterpret_cast<const Elf_Ehdr *>(base()); ... // Scan sections for special sections. for (Elf_Shdr_Iter SecI = begin_sections(), SecE = end_sections(); SecI != SecE; ++SecI) { ... ec = error_code::success(); } Stepping through the disassembled code, I can see that the Buf(Object) happens before the call to base() (which does Buf->getBufferStart()), and that ec's initialization happens before Header's, which is ok, but part of the call to the iterator code, which is inlined, gets executed before Header is initialized, so the base of the pointer operator()-> is 0x0. LLVM's code seems correct, so I think this is just a bug in GCC 4.7.2. I'm not sure I have a way to reduce this case to report it to the GCC list, but we could either revert our GCC version to 4.6.3 (which is working with all other buildbots), or change the CFLAGS to -O2.
I'm not an Arch expert and I cannot find an easy way to install either gcc 4.6 or 4.8, so I think the interim solution is to change CFLAGS to -O2.
New error at -O2 with gcc 4.7.2: g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. /home/user/devel/buildbot/localbot/clang-native-arm-cortex-a15-arch/llvm/Makefile.rules:1464: recipe for target '/home/user/devel/buildbot/localbot/clang-native-arm-cortex-a15-arch/llvm/tools/clang/unittests/Tooling/Release+Asserts/RecursiveASTVisitorTest.o' failed make[4]: *** [/home/user/devel/buildbot/localbot/clang-native-arm-cortex-a15-arch/llvm/tools/clang/unittests/Tooling/Release+Asserts/RecursiveASTVisitorTest.o] Error 1 I'm beginning to think we should not use ODroid XU for buildbots, or we're going to have the same nightmare we had with Pandas, at least not until we can get a different GCC version. At Linaro we use the XU, but the GCC is compiled by hand, from a specific version. I'll see if we can get a binary distribution of it and use it.
Mikael found the GCC 4.8 we can use (and got his bot green). http://www.archfrog.org/GCC-4.8.2-armv7h His instructions: Install using: pacman -U xxx.pkg.tar.xz Please notice that libtool must be uninstalled prior to installing GCC v4.8.2 (pacman -R libtool); unfortunately my build of libtool was stopped abruptly by a failure in the libtool test case. I have reported this to GNU and am now awaiting their response and/or fix.