Uh oh!
There was an error while loading. Please reload this page.
add --soft-float option - #9617
Conversation
There was a problem hiding this comment.
I'm not entirely sure where soft/hard comes into play, but it seems unfortunate to add another flag to the compiler (which we try to keep to a small number).
Is this something which is more of a property of the target triple? It looks like it's on by default for MIPS, so should it always be on by default for mips? Or is it something where one triple of mips has soft floats and one triple has hard floats? Basically it'd be nice to infer soft/hard somehow instead of having to explicitly specify it.
There was a problem hiding this comment.
The MIPS target of LLVM generates FPU instructions by default and there is no way to specify soft float in MIPS triple.
I enable soft float by default because I think it works on most MIPS CPUs.
I don't know what is the best way to handle this option.
Is it acceptable to hardcode softfp option in LLVMRustCreateTargetMachine like this
if (Trip.getArch() == Triple::mips) {
Options.UseSoftFloat = true;
Options.FloatABIType = FloatABI::Soft;
}
There was a problem hiding this comment.
It looks like LLVM has a command-line flag for generating soft-float calls, have you tried rustc --llvm-args '-soft-float' to see if LLVM is actually picking it up from the command line?
There was a problem hiding this comment.
I tried and failed. It said Unknown command line argument '-soft-float'.
There was a problem hiding this comment.
Hm that's unfortunate. This seems more like something we'd desire from LLVM, but perhaps they have a reason they don't have a feature/cpu flag for supporting this. I'd be more comfortable putting this behind a -Z flag than making it a first-class command line argument. I realize that -Z has recently become a bit of a "dumping ground", but this does seem like it fits better there than as a main command line parameter (although I could be wrong).
There was a problem hiding this comment.
I replaced --soft-float with -Z soft-float.
lucab
commented
Sep 30, 2013
At least on ARM this is shown in the triplet (eg. arm-linux-gnueabihf vs. arm-linux-gnueabi). But I couldn't find any hf ABI for mips in glibc https://sourceware.org/git/?p=glibc.git;a=blob;f=ports/sysdeps/mips/preconfigure;h=b215eb2c17a738d21b1b62404fc6e6054757d8c3;hb=HEAD |
There was a problem hiding this comment.
Can't this become part of --target-cpu or --target-feature? (Or are they passed straight to LLVM and LLVM doesn't have an option of this form to specify soft-float?)
There was a problem hiding this comment.
Unfortunately, softfp of MIPS target can only be specified by TargetOptions::UseSoftFloat and this option can not be set by --target-cpu or --target-feature or other LLVM options.
This change adds -Z soft-float option for generating software floating point library calls. It also implies using soft float ABI, that is the same as llc. It is useful for targets that have no FPU.
This change adds --soft-float option for generating software floating point library calls. It also implies using soft float ABI, that is the same as llc. It is useful for targets that have no FPU.
Right now two MIPS targets in the compiler, `mips-unknown-linux-{gnu,musl}` both
generate object files using the soft-float ABI through LLVM by default. This is
also expressed as the `-C soft-float` codegen option and otherwise isn't used
for any other target in the compiler. This option was added quite some time ago
(back in rust-lang#9617), and nowadays it's more appropriate to be done through a codegen
option.
This is motivated by rust-lang#34743 which necessitated an upgrade in the CMake
installation on our bots which necessitated an upgrade in the Ubuntu version
which invalidated the MIPS compilers we were using. The new MIPS compilers
(coming from Debian I believe) all have hard float enabled by default and soft
float support not built in. This meant that we couldn't upgrade the bots
until rust-lang#34841 landed because otherwise we would fail to compile C code as the
`-msoft-float` option wouldn't work.
Unfortunately, though, this means that once we upgrade the bots the C code we're
compiling will be compiled for hard float and the Rust code will be compiled
for soft float, a bad mismatch! This PR remedies the situation such that Rust
will compile with hard float as well.
If this lands it will likely produce broken nightlies for a day or two while we
get around to upgrading the bots because the current C toolchain only produces
soft-float binaries, and now rust will be hard-float. Hopefully, though, the
upgrade can go smoothly!rustc: Remove soft-float from MIPS targets
Right now two MIPS targets in the compiler, `mips-unknown-linux-{gnu,musl}` both
generate object files using the soft-float ABI through LLVM by default. This is
also expressed as the `-C soft-float` codegen option and otherwise isn't used
for any other target in the compiler. This option was added quite some time ago
(back in rust-lang#9617), and nowadays it's more appropriate to be done through a codegen
option.
This is motivated by rust-lang#34743 which necessitated an upgrade in the CMake
installation on our bots which necessitated an upgrade in the Ubuntu version
which invalidated the MIPS compilers we were using. The new MIPS compilers
(coming from Debian I believe) all have hard float enabled by default and soft
float support not built in. This meant that we couldn't upgrade the bots
until rust-lang#34841 landed because otherwise we would fail to compile C code as the
`-msoft-float` option wouldn't work.
Unfortunately, though, this means that once we upgrade the bots the C code we're
compiling will be compiled for hard float and the Rust code will be compiled
for soft float, a bad mismatch! This PR remedies the situation such that Rust
will compile with hard float as well.
If this lands it will likely produce broken nightlies for a day or two while we
get around to upgrading the bots because the current C toolchain only produces
soft-float binaries, and now rust will be hard-float. Hopefully, though, the
upgrade can go smoothly!add `cast-nan-to-int` lint This fixesrust-lang#371. r? `@Alexendoo` --- changelog: add [`cast-nan-to-int`] lint
…uwer remove -Csoft-float This fixesrust-lang#129893 by removing the offending flag. The flag has been added in pre-1.0 times (rust-lang#9617) without much discussion, probably with the intent to mirror `-msoft-float` in C compilers. It never properly mirrored clang though because it only affected the LLVM float ABI setting, not the "soft-float" target feature (the clang flag sets both). It is also blatantly unsound because it affects how float arguments are passed, making it UB to invoke parts of the standard library. The flag got deprecated with Rust 1.83 (released November 2024), and in the year since then, nobody spoke up in rust-lang#129893 to have it preserved. I think it is time to remove it. I can totally imagine us bringing back a similar flag, properly registered as a target modifier to preserve soundness, but that should come with a coherent design that works for more than one architecture (the flag only does anything on ARM). Blocked on approval of rust-lang/compiler-team#971. Fixesrust-lang#154106
9637: Overhaul doc_links testing infra r=Veykril a=Veykril and fix several issues with current implementation. Fixesrust-lang#9617 Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
This change adds --soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.