diff options
author | Sam Clegg <sbc@chromium.org> | 2019-12-19 17:30:24 -0800 |
---|---|---|
committer | Sam Clegg <sbc@chromium.org> | 2020-02-11 17:36:15 -0800 |
commit | b062fe181625bd1944ca9ca2a58246ffd7cd3536 (patch) | |
tree | 203e58c290a6691f660375c6e85dfe7c5fa59ff9 /llvm/lib/Support/ErrorHandling.cpp | |
parent | 2f172d8d3c10ea7538818cbfffeb54ef30bb1a11 (diff) | |
download | llvm-b062fe181625bd1944ca9ca2a58246ffd7cd3536.zip llvm-b062fe181625bd1944ca9ca2a58246ffd7cd3536.tar.gz llvm-b062fe181625bd1944ca9ca2a58246ffd7cd3536.tar.bz2 |
[lld][WebAssembly] Fail if bitcode objects are pulled in after LTO
This can happen if lto::LTO::getRuntimeLibcallSymbols doesn't return
an complete/accurate list of libcalls. In this case new bitcode
object can be linked in after LTO.
For example the WebAssembly backend currently calls:
setLibcallName(RTLIB::FPROUND_F32_F16, "__truncsfhf2");
But `__truncsfhf2` is not part of `getRuntimeLibcallSymbols` so if
this symbol is generated during LTO the link will currently fail.
Without this change the linker crashes because the bitcode symbol
makes it all the way to the output phase.
See: https://bugs.llvm.org/show_bug.cgi?id=44353
Differential Revision: https://reviews.llvm.org/D71632
Diffstat (limited to 'llvm/lib/Support/ErrorHandling.cpp')
0 files changed, 0 insertions, 0 deletions