-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

[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.

[thejpster]

On the Cortex-R52, the FPU is mandatory and if anyone wants compatibility with older soft-float code they can either use armv7r-none-eabi, or they can come and make a compelling case for the v8-R version (kernel developers? idk). I'm not minded to add it on a whim because it seems pretty niche.

[workingjubilee]

This flag has a very "from the days when there was an OABI" vibe to it.

[workingjubilee]

I think we should start by warning when this flag is used, maybe that will get someone to explain their hypothetical use-case that cannot possibly be replaced by the -Ctarget-feature route.

[RalfJung]

I think we should start by warning when this flag is used, maybe that will get someone to explain their hypothetical use-case that cannot possibly be replaced by the -Ctarget-feature route.

All right, I made #129897 do exactly that now.

[apiraino]

WG-prioritization assigning priority on Zulip.

Also, (related discussion).

@rustbot label -I-prioritize +P-medium

[skade]

On the Cortex-R52, the FPU is mandatory and if anyone wants compatibility with older soft-float code they can either use armv7r-none-eabi, or they can come and make a compelling case for the v8-R version (kernel developers? idk). I'm not minded to add it on a whim because it seems pretty niche.

A good soft/no-float story is highly desired by Rust for Linux (and other kernel developers): Rust-for-Linux/linux#514

There's the clippy lint to avoid floats, but it runs into the same issue as this flag: lints are crate per crate, while this should be binary by binary.

[RalfJung]

A good soft/no-float story is highly desired by Rust for Linux (and other kernel developers): Rust-for-Linux/linux#514

That will almost surely evolve around -Ctarget-feature=+soft-float, or some new way of exposing that target feature, not around -Csoft-float. The -C flag is mostly a red herring and confusing. See the discussion above for more details.

[RalfJung]

@jamesmunns you brought this issue up in wg-embedded discussions. Is this flag something that embedded code relies on today? Note that this is only about -Csoft-float, not about using -Ctarget-feature to toggle between soft-floats and hard-floats.

Basically I am trying to figure out which timeline we can go for here in terms of making -Csoft-float a hard error. Is anyone currently relying on that flag? Do we have to wait for some project to migrate to a better option? Do we have to wait for a better option to be made available?

This warning will hit stable with the 1.83 release in 2 weeks. Then we should probably wait a release or two for people to notice this warning and get in touch with us if they rely on this flag. So I would hope to make this a hard error in nightly around February 2025, to hit stable either with 1.86 or 1.87.

OTOH, this flag could also become part of the target modifiers system (Cc @Darksonn), in which case the timeline would be "whenever mismatching target modifiers without an explicit override become a hard error". Though I think even then we should make it a hard error (without offering an override) to set this flag on any target where it doesn't actually do anything. Also, we already have *hf and non-hf targets on 32bit ARM, so it's a bit unclear whether we really want that and this flag.

[jamesmunns]

I don't believe that anyone in the wg-embedded discussions was using -Csoft-float. I can ping again, but as mentioned above, most embedded folks just use the soft-float targets (non-hf). We mostly deal with bare metal/RTOS systems where you are compiling everything at once. I can't remember it being mentioned at all prior to this issue.

[jamesmunns]

Ah, I did managed to find some usage of this in Redox: https://grep.app/search?q=-C%20soft-float

CC @jackpot51

[RalfJung]

Redox should have been fixed by https://gitlab.redox-os.org/redox-os/cookbook/-/merge_requests/392. Or does it use the flag in more than one place?

From these search results you linked, none of them seems to be on 32bit ARM, so the flag is anyway already a NOP.

[RalfJung]

Long-term we could also consider making this flag actually work on all targets (probably with a warning on targets that are already soft-float targets). But that will require gathering some data to figure out which target features and other things need to be set on any given target to make it a valid soft-float target.