build-std + link-dead-code=y cannot build custom target without sse

[jzbor]

Hi,
I am trying to compile my Rust OS kernel for x86_64. As I don't want to implement SSE support for multiple reasons, I chose the +soft-float feature. This does not seem to work with build-std:

   Compiling compiler_builtins v0.1.108
   Compiling core v0.0.0 (/home/jzbor/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling mosk v0.1.0 (/home/jzbor/Programming/Rust/mosk)
   Compiling rustc-std-workspace-core v1.99.0 (/home/jzbor/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
rustc-LLVM ERROR: Do not know how to split this operator's operand!

error: could not compile `core` (lib)
warning: build failed, waiting for other jobs to finish...

For my features I currently use

"features": "-mmx,-sse,+soft-float"

I have also tried adding -sse2 and -avx with pretty much the same result.

Enabling SSE in the custom target works, but of course results in errors at runtime, as I don't actually implement SSE support.

I have found several related issues, but none of them seem to track this specific problem:
#63466 #92760 #62729

#63466 seems to also be referenced by official documentation as known issue, although it is closed and does not seem to track actually fixing the issue.

I have tried the workaround suggested in #62729 without success.

This is my full custom target:

{
	"llvm-target": "x86_64-unknown-none",
	"data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128",
	"arch": "x86_64",
	"target-endian": "little",
	"target-pointer-width": "64",
	"target-c-int-width": "32",
	"os": "none",
	"executables": true,
	"linker-flavor": "ld.lld",
	"linker": "rust-lld",
	"panic-strategy": "abort",
	"disable-redzone": true,
	"features": "-mmx,-sse,+soft-float"
}

EDIT: Cargo version and rust version

cargo 1.79.0-nightly (499a61ce7 2024-03-26)
rustc 1.79.0-nightly (c9f8f3438 2024-03-27)

EDIT2: I found out this only happens with -C link-dead-code=y, which I require in order to link assembly code. If this option is not set the linker will remove some of the assembly sections.

[taiki-e]

"features": "-mmx,-sse,+soft-float"

It seems that builtin x86_64-unknown-none target uses "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2,+soft-float".

$ rustc -Z unstable-options --print target-spec-json --target x86_64-unknown-none | grep features
  "features": "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2,+soft-float",

rust/compiler/rustc_target/src/spec/targets/x86_64_unknown_none.rs

Lines 21 to 22 in c0ddaef

	features:
	"-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2,+soft-float"

[jzbor]

This produces the same error. Maybe the problem is rather with link-dead-code=y than the actual features. I wouldn't know however why this should interfere with core compilation. Also I am not sure how else to convince the linker of leaving my sections in.

[jzbor]

Ok so I have added a KEEP(...) instruction to the relevant section of the linker script and it seems to work fine now. I am still confused however to why link-dead-code causes this issue.

Feel free to close this issue if you simply consider link-dead-code + build-std not supported.

[saethlin]

This looks like an LLVM bug that's been exposed by having to compile the additional code that's only included with -Clink-dead-code.

[workingjubilee]

afaik we do not test whether std has correct behavior when built with -Clink-dead-code, yes.

[workingjubilee]

I'm taking the reporter's option here:

Feel free to close this issue if you simply consider link-dead-code + build-std not supported.

Formally, -Clink-dead-code is a stable feature, and -Zbuild-std is an unstable feature. Honestly though, actually using them, -Clink-dead-code feels like the unstable feature, and -Zbuild-std feels like a stable feature, in terms of relative jank.

It's unclear what they really ought to even do when combined together.

So I think we definitely do not consider them supported together, unfortunately.