aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/ErrorHandling.cpp
diff options
context:
space:
mode:
authorSam Clegg <sbc@chromium.org>2019-12-19 17:30:24 -0800
committerSam Clegg <sbc@chromium.org>2020-02-11 17:36:15 -0800
commitb062fe181625bd1944ca9ca2a58246ffd7cd3536 (patch)
tree203e58c290a6691f660375c6e85dfe7c5fa59ff9 /llvm/lib/Support/ErrorHandling.cpp
parent2f172d8d3c10ea7538818cbfffeb54ef30bb1a11 (diff)
downloadllvm-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