forked from OSchip/llvm-project
b062fe1816
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 |
||
|---|---|---|
| .. | ||
| Inputs | ||
| archive.ll | ||
| atomics.ll | ||
| cache.ll | ||
| comdat.ll | ||
| diagnostics.ll | ||
| export.ll | ||
| import-attributes.ll | ||
| incompatible.ll | ||
| internalize-basic.ll | ||
| libcall-archive.ll | ||
| libcall-truncsfhf2.ll | ||
| lto-start.ll | ||
| opt-level.ll | ||
| parallel.ll | ||
| relocatable-undefined.ll | ||
| relocatable.ll | ||
| save-temps.ll | ||
| signature-mismatch.ll | ||
| thinlto.ll | ||
| undef.ll | ||
| used.ll | ||
| verify-invalid.ll | ||
| weak-undefined.ll | ||
| weak.ll | ||