[llvm-dev] Please dogfood LLD

[Davide Italiano via llvm-dev]

On Thu, Mar 16, 2017 at 1:07 AM, David Chisnall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 16 Mar 2017, at 06:14, Sean Silva <chisophugis at gmail.com> wrote:
>>
>> On Wed, Mar 15, 2017 at 2:55 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On 14 Mar 2017, at 18:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> >
>> > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS).
>>
>> We’re now using it with all three architectures on FreeBSD (though only the n64 ABI for MIPS) and will file bugs.  One QoI issue that’s bitten us a couple of times is that the versions of clang and lld must match for LTO to work.  If they don’t, we don’t get an error message, we simply get programs that segfault on startup.  I’m a bit surprised that reading the bitcode doesn’t return an error that LLD can report and refuse to link.  We’ve seen this error mixing clang 4.0 and lld trunk.
>>
>> If you can put a --reproduce archive up somewhere and file a bug that would be really useful. The bitcode should be backward compatible. I would not be surprised by older LLD and newer Clang causing issues, but the reverse Should Work.
>
> It appears that I’d misdiagnosed the problem.  Even with matching versions, I get a non-functional tablegen for a thin LTO build on FreeBSD, but when I set them to identical versions CMake had failed to pick up the LTO instruction and so was doing a normal non-LTO build.
>

Any chances you can report the llvm-tblgen failure? I built that all
the time (even with ThinLTO and I've never seen it, so I'm a little
surprised).

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare