-Csoft-float flag is unsound

[RalfJung]

Current status: all use of the flag causes a warning (will be shipped in 1.83), announcing that it will become a hard error in the future.

---

@bjorn3 just made me aware of this amazing flag:

    -C               soft-float=val -- use soft float ABI (*eabihf targets only) (default: no)

This is quite unsound: if code gets compiled with -Csoft-float and calls code from the standard library that uses the hard float ABI, we have UB. Generally we need different target triples for softfloat vs hardfloat ABIs, since (as per the discussion in rust-lang/lang-team#235) code within a single target should be ABI compatible. Cargo even (unstably) allows overwriting RUSTFLAGS on a per-crate basis, so we better make sure crates compiled with different flags can be linked with each other.

This was added a looooong time ago in #9617. I couldn't find any discussion regarding its soundness.

We have e.g. arm-unknown-linux-musleabi and arm-unknown-linux-musleabihf, so using the *hf target but with -Csoft-float also seems kind of unnecessary. (But I have not checked whether all eabihf targets have a corresponding eabi target.)

According to the documentation, this can only be used by ARM targets. So paging in some ARM folks -- is this used in practice, and if yes, how do people avoid the soundness problems?
@rustbot ping arm

Note that this issue is not about -Ctarget-feature=+soft-float, see #116344 for that.

[rustbot]

Hey ARM Group! This bug has been identified as a good "ARM candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @adamgemmell @hug-dev @jacobbramley @JamieCunliffe @joaopaulocarreiro @raw-bin @Stammark

[RalfJung]

Rustc just always forwards this flag to LLVM, so it seems possible that the *eabihf targets only part of the docs is not correct. We're certainly seeing a bunch of people out there setting this on non-ARM targets (e.g. here are some uses on x86 and riscv).

Cc @parched who added this part to the docs in #36261. Does LLVM document anywhere what this flag does, and which targets it affects?

[Dirbaio]

(hi from from the embedded side. i'm mostly familiar with the thumb*eabi(hf)? targets, i'm not sure about others)

One use of the flag is to allow using the FPU while still using the soft-float ABI for compatibility with other code. However, this can already be done by using the -eabi targets and then telling the compiler to use the FPU anyway with some -Ctarget-feature, which seems a much less dangerous way of doing it.

I can't think of any other uses, so I wouldn't oppose deprecating/removing it.

[RalfJung]

Seems like this flag is called -mfloat-abi in GCC/clang and indeed only exists for ARM. So most uses out there are bogus. A first step might be for us to show a warning when the flag is used on a target where it has no effect.

One use of the flag is to allow using the FPU while still using the soft-float ABI for compatibility with other code. However, this can already be done by using the -eabi targets and then telling the compiler to use the FPU anyway with some -Ctarget-feature, which seems a much less dangerous way of doing it.

Yes indeed, if there's a way to tell LLVM "use soft-float ABI but also use FPU", in a way that doesn't affect the ABI at all as is entirely link-compatible with fully soft-float code, then that's what should be done.

[RalfJung]

Hm, either I am misunderstanding the assembly or this feature does not work as advertised? https://godbolt.org/z/53W75s3fc seems to show that -Csoft-float does not actually change the ABI?

EDIT: Ah no I just can't read assembly. This still uses hard-float operations but first moves the data from rN to sN, i.e. it expects a soft-float ABI. Never mind.

[RalfJung]

Here are the eabihf targets that do not have a corresponding eabi target, and thus might rely on -Csoft-float to get a soft-float ABI:

• thumbv7neon-unknown-linux-gnueabihf (tier 2)
• armv6-unknown-netbsd-eabihf (tier 3)
• armv7-sony-vita-newlibeabihf (tier 3)
• armv7-unknown-netbsd-eabihf (tier 3)
• armv7-wrs-vxworks-eabihf (tier 3)
• armv8r-none-eabihf (tier 3)
• thumbv7neon-unknown-linux-musleabihf (tier 3)

So, only one tier 2 target is affected. And it's a tier 2 target without listed maintainers.

[bjorn3]

armv7-sony-vita-newlibeabihf is meant to be used with a single cpu only which supports floats, so there is probably no need for soft-float support for that target.

[thejpster]

Turning off the hard float ABI on a hard float target sounds like a "why do we even have that lever" kind of deal. I can't imagine why anyone would want to and I expect it would end badly if they tried.

As others have said, adding FPU instructions into a soft-float build is a entirely different matter, as is enabling Helium (MVE) or anything else that affects the juicy centre of a function but not its hard outer shell.