-Csoft-float flag is unsound about rust HOT 13 OPEN

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

from rust.

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

from rust.

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?

from rust.

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.

from rust.

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.

from rust.

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.

from rust.

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.

from rust.

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.

from rust.

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.

from rust.

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

from rust.

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.

from rust.

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.

from rust.

WG-prioritization assigning priority on Zulip.

Also, (related discussion).

@rustbot label -I-prioritize +P-medium

from rust.