We were previously hitting assertion failures in the writer in cases where a regular object file defined a weak external symbol that was defined by a bitcode file. Because /export and /entry name mangling were implemented using weak externals, the same problem affected mangled symbol names in bitcode files. The underlying cause of the problem was that weak external symbols were being resolved before doing LTO, so the symbol table may have contained stale references to bitcode symbols. The fix here is to defer weak external symbol resolution until after LTO. Also implement support for weak external symbols in bitcode files by modelling them as replaceable DefinedBitcode symbols. Differential Revision: http://reviews.llvm.org/D10940 llvm-svn: 241391
7 lines
156 B
LLVM
7 lines
156 B
LLVM
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64-pc-windows-msvc18.0.0"
|
|
|
|
define void @"\01?main@@YAHXZ"() {
|
|
ret void
|
|
}
|