-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.O-windowsOperating system: WindowsOperating system: WindowsP-lowLow priorityLow priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Description
I think #96444 might have broken the #[export_name = "\x01..."] LLVM workaround for avoiding the "@xyz" name mangling on x86. Compiling the following with i686-pc-windows-msvc
results in error LNK2001: unresolved external symbol _☺test1@0
:
#[export_name = "\x02test2"]
extern "stdcall" fn test2() {}
#[export_name = "\x01test1"]
extern "stdcall" fn test1() {}
I stumbled upon this when trying to use the \x01
workaround to specify the _aulldiv
symbol, which the MSVC linker expects to be named __aulldiv
(instead of __aulldiv@16
) in #![no_std]
x86 Windows crates.
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.O-windowsOperating system: WindowsOperating system: WindowsP-lowLow priorityLow priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.