GNU LLD build error? Seems that Clang likes LLD just fine.

Hi,

I am trying to add a PowerPC/GNU LLD builder. Therefore I am building manually until everything is fine and I can link the builder into Zorg.

It almost completed but then I got this error:

[ 97%] Building CXX object tools/lld/lib/ReaderWriter/ELF/X86_64/CMakeFiles/lldX86_64ELFTarget.dir/X86_64LinkingContext.cpp.o
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp: In member function ‘virtual llvm::ArrayRef<unsigned char> {anonymous}::X86_64InitAtom::rawContent() const’:
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp:40:12: error: could not convert ‘(const uint8_t*)(& {anonymous}::x86_64InitFiniAtomContent)’ from ‘const uint8_t* {aka const unsigned char*}’ to ‘llvm::ArrayRef<unsigned char>’
     return x86_64InitFiniAtomContent;
            ^
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp: In member function ‘virtual llvm::ArrayRef<unsigned char> {anonymous}::X86_64FiniAtom::rawContent() const’:
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp:56:12: error: could not convert ‘(const uint8_t*)(& {anonymous}::x86_64InitFiniAtomContent)’ from ‘const uint8_t* {aka const unsigned char*}’ to ‘llvm::ArrayRef<unsigned char>’
     return x86_64InitFiniAtomContent;
            ^
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp: In member function ‘virtual llvm::ArrayRef<unsigned char> {anonymous}::X86_64InitAtom::rawContent() const’:
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp:41:3: warning: control reaches end of non-void function [-Wreturn-type]
   }
   ^
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp: In member function ‘virtual llvm::ArrayRef<unsigned char> {anonymous}::X86_64FiniAtom::rawContent() const’:
/home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp:57:3: warning: control reaches end of non-void function [-Wreturn-type]
   }
   ^
make[2]: *** [tools/lld/lib/ReaderWriter/ELF/X86_64/CMakeFiles/lldX86_64ELFTarget.dir/X86_64LinkingContext.cpp.o] Error 1
make[1]: *** [tools/lld/lib/ReaderWriter/ELF/X86_64/CMakeFiles/lldX86_64ELFTarget.dir/all] Error 2
make: *** [all] Error 2

It seems to me that there is a possible incompatibility between GCC v4.8.2 and Clang because the Clang builders did the build without errors.  I am using the -std=c++11 flag to GCC.  
Any advice on how to proceed?  The problem seems related to a recent change that eliminated the makeArrayRef() call in that very module.  Perhaps GCC and Clang differ in opinion on when to do automatic casts are not?


-- Mikael

I didn’t even look at your errors, but my understanding is that -std=gnu++11 is more used (and much better tested) than -std=c++11. Any chance that fixes it for you?

FYI

The same problem on gcc 4.7/4.8/4.9 with -std=c++11 and -std=gnu++11.
It looks like a bug in the gcc but that fact does not help to build
lld.

I’ll give it a try, thanks.

– Mikael

Yup, I can confirm that. Then the question is if LLD shouldn’t compile with GNU, even if GNU is buggy. Personally, I think it is worth a lot to be able to build with GCC, but I don’t know how the LLD developers feel about that.

– Mikael

We should make LLD to be able to build with GCC even if GCC is a bit buggy. So you wrote that it’s no longer build because of the recent change of makeArrayRef removal? I think it’s my change (r196475).

Can you confirm that you can build if you revert that change? If it has caused the build with GCC to break, we should roll it back.

I tried this command to undo the change (which should revert to the change just before the one you mentioned):

svn update -rr196474

Then I built from scratch. This time it built, so I suppose it is revision 196475 that is the problem.

– Mikael

Thanks for checking! Rolled back the problematic patch in r196853.