Repository navigation
Closed
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-linuxOperating system: LinuxOperating system: LinuxO-windowsOperating system: WindowsOperating system: WindowsT-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-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Description
Any crate that uses std::sync::Arc fails to compile with a link error saying unresolved external symbol __atomic_fetch_sub_8
Test case on rustc 1.38.0-nightly (6a91782b7 2019-08-06)
fn main() {
let test = std::sync::Arc::new(32);
}outputs:
link_error-44aa39a2e793d984.29ne1tatqckt0j9r.rcgu.o : error LNK2019: unresolved external symbol __atomic_fetch_sub_8 referenced in function _ZN4core4sync6atomic10atomic_sub17hb46c24bb21c6d0b1E
or from a bigger project:
build_script_build-10d0cb3662789960.build_script_build.brrzdj7n-cgu.18.rcgu.o : error LNK2019: unresolved external symbol __atomic_fetch_sub_8 referenced in function
_ZN5alloc4sync12Arc$LT$T$GT$9drop_slow17h215332bbcf7e5cb5E
build_script_build-10d0cb3662789960.build_script_build.brrzdj7n-cgu.20.rcgu.o : error LNK2001: unresolved external symbol __atomic_fetch_sub_8
F:\code\projects\active\untitled\target\debug\build\byteorder-10d0cb3662789960\build_script_build-10d0cb3662789960.exe : fatal error LNK1120: 1 unresolved externals
Nightly rustc 1.38.0-nightly (4bb6b4a5e 2019-07-11)/nightly-2019-07-12-x86_64-pc-windows-msvc works totally fine.
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-linuxOperating system: LinuxOperating system: LinuxO-windowsOperating system: WindowsOperating system: WindowsT-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-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Activity
Mark-Simulacrum commentedon Aug 7, 2019
Is this reproducible after
cargo clean?novacrazy commentedon Aug 7, 2019
Yes, happens on a fresh project I made for testing (
cargo new) and aftercargo cleanMark-Simulacrum commentedon Aug 7, 2019
4bb6b4a...6a91782 is the full commit range, which notably includes an LLVM upgrade #62592 -- cc @nikic
Could you check with https://crates.io/crates/rustup-toolchain-install-master/ if 07e0c36 is fine and 38798c6 is broken for you?
novacrazy commentedon Aug 7, 2019
I can confirm that 07e0c36 works fine but 38798c6 is broken.
Also, that's a nifty tool.
Mark-Simulacrum commentedon Aug 7, 2019
Okay, LLVM update is then definitely at fault, cc @alexcrichton
ollie27 commentedon Aug 7, 2019
With default settings I'm not reproducing this locally with
rustc 1.38.0-nightly (6a91782b7 2019-08-06)onx86_64-pc-windows-msvc. Do you have any rustflags set in your cargo config orRUSTFLAGSenvironment variable? What is the full output ofcargo build --verbose?novacrazy commentedon Aug 7, 2019
Here is the full failing output from
cargo build --verboseDetails
Indeed, my
RUSTFLAGSare set to$env:RUSTFLAGS = "-C target-cpu=native"Testing again without
-C target-cpu=nativedoes not error, and compiles/runs fine.novacrazy commentedon Aug 7, 2019
If it helps, I'm on AMD Zen v1, or
target-cpu=znver1, and it looks likeznver2was introduced in the LLVM upgrade.mati865 commentedon Aug 8, 2019
Fails the same way on Linux (GNU and musl) and Windows GNU using
RUSTFLAGS="-C target-cpu=native" cargo runon Ryzen 2700X platform so it probably affects all the OSes.Details
@rustbot modify labels: -E-needs-bisection -O-windows-msvc +O-linux +O-windows +A-LLVM
1 remaining item
alexcrichton commentedon Aug 8, 2019
This seems like LLVM's auto-detection of what CPU is on the host or what the target features your native CPU has may be broken. The next step for this is to probably use a build of Clang to reproduce and then report this upstream to LLVM itself.
alexcrichton commentedon Aug 8, 2019
Er sorry I have a guess as to where this is but I do not have time to investigate this right now, so I'm going to unassign myself since I can't take care of this.
mati865 commentedon Aug 8, 2019
Minimised:
IR:
atomic.ll.txt
atomic_znver1.ll.txt
I cannot build Clang/LLVM from master right now so I'm attaching IR from my code above. I'll try to find time tomorrow or somewhere next week.
nikic commentedon Aug 8, 2019
Confirming that
produces a
__atomic_fetch_sub_8call instead of alock xaddqunderllc -mcpu=znver1.nikic commentedon Aug 8, 2019
I believe the cause is that the znver feature spec is missing
FeatureCMPXCHG8B(the 16B variant is listed).nikic commentedon Aug 8, 2019
LLVM bug reported at https://bugs.llvm.org/show_bug.cgi?id=42935.
Auto merge of #63415 - nikic:bump-llvm-2, r=alexcrichton