c-variadic: multiple ABIs in the same program for arm #144541
Conversation
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
|
@bors2 try |
…bis-arm, r=<try> c-variadic: multiple ABIs in the same program for arm try-job: armhf-gnu
| "only-aarch64-unknown-linux-gnu", | ||
| "only-apple", | ||
| "only-arm", | ||
| "only-arm-unknown-linux-gnueabihf", |
There was a problem hiding this comment.
@jieyouxu is this the right thing to do here?
There was a problem hiding this comment.
To let more targets through (as requested below), we can instead allow only-eabihf. That is not perfect, because there are aebi (no hf) targets that still do support executing floating point instructions, but it at least casts a wider net.
Maybe ignore-softfloat could work. I'm not sure how to check for that actually working, from what I can tell the arm targets generally still support floating point instructions, even if they don't pass arguments via fp registers.
There was a problem hiding this comment.
is this the right thing to do here?
This depends on why you need to have the test run on only-arm-unknown-linux-gnueabihf specifically. I think it's fine if we don't really have a good way to partition the targets as @folkertdev describes.
Also yeah, if this is actually about targets with hard float support, maybe something based on that would be better.
There was a problem hiding this comment.
What I meant is, do we just have to add this here? I am surprised there's no new code implementing the logic for this filter.^^
There was a problem hiding this comment.
What I meant is, do we just have to add this here? I am surprised there's no new code implementing the logic for this filter.^^
Yes, that would be sufficient. This filter is only meant to catch unknown directives (I haven't gotten around to getting rid of it yet), but compiletest actually already have logic to accept //@ only-$target_tuple for all target tuples.
| @@ -0,0 +1,62 @@ | |||
| #![feature(extended_varargs_abi_support)] | |||
| //@ run-pass | |||
| //@ only-arm-unknown-linux-gnueabihf | |||
There was a problem hiding this comment.
Why only that one specific target? (And not all arm targets, or so)
There was a problem hiding this comment.
the assembly needs hardware floats, and we're using floats because that is one case where we know aapcs and C are different. We don't have a nice way of filtering for hardware float. Also this is a target that actually runs on CI.
There was a problem hiding this comment.
we're using floats because that is one case where we know aapcs and C are different
Please always put such choices into comments! The chance that someone else reading the code will realize this without a comment is probably negligible.
There was a problem hiding this comment.
this is a target that actually runs on CI.
That may change though...
Would it work to enable the test on all ARM targets, and then inside the test use a cfg!(target_abi) to neuter it when we don't have floats? Then at least if CI switches to some other arm eabihf target the test will still run.
|
Hey ARM Group! This bug has been identified as a good "ARM candidate". cc @adamgemmell @davidtwco @hug-dev @jacobbramley @JamieCunliffe @joaopaulocarreiro @raw-bin @Stammark |
7c6fa6a to
5440cce
Compare
|
☔ The latest upstream changes (presumably #144673) made this pull request unmergeable. Please resolve the merge conflicts. |
5440cce to
74c6fdf
Compare
|
With the ARM approval we're good to go here, right? |
|
@bors r=RalfJung,davidtwco |
Rollup of 16 pull requests Successful merges: - #137494 (libstd: init(): dup() subsequent /dev/nulls instead of opening them again) - #144541 (c-variadic: multiple ABIs in the same program for arm) - #144613 (aarch64-nintendo-switch-freestanding - Enable CPU features that are always available in a live system (crypto instructions, plus explicit NEON).) - #144780 (Add a method to dump MIR in the middle of MIR building) - #145137 (Consolidate panicking functions in `slice/index.rs`) - #145507 (Refactor attribute parsing to improve ergonomics and some diagnostics) - #145604 (Gate static closures behind a parser feature) - #145648 (Add two tidy dependency checks) - #145661 (update some s390x codegen tests) - #145672 (Instantiate higher-ranked binder with erased when checking `IntoIterator` predicate for query instability) - #145689 (Migrate `panic_unwind` to use `cfg_select!`) - #145700 (Handle `ReEarlyParam` in `type_name`.) - #145703 (Remove MIPS targets from CI LLVM platforms) - #145704 (ci: don't cleanup windows disk) - #145705 (remove an `as` cast in prefetch codegen) - #145712 (Update outdated link in bound region comments) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #144541 - folkertdev:c-variadic-same-program-multiple-abis-arm, r=RalfJung,davidtwco c-variadic: multiple ABIs in the same program for arm similar to #144379, but for arm, requested in #144066. Quoting rust-lang/reference#1946 (comment) > `"aapcs"` specifically refers to the soft-float ABI where floating-point values are passed in integer registers. However for c-variadic functions, `aapcs` behaves the same as `C`: https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#65parameter-passing > A variadic function is always marshaled as for the base standard. https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#7the-standard-variants > This section applies only to non-variadic functions. For a variadic function the base standard is always used both for argument passing and result return. --- I also noticed that rustc currently emit more instructions than clang for c-variadic functions on arm, see https://godbolt.org/z/hMce9rnTh. I'll fix that separately. (edit: #144549) try-job: armhf-gnu r? `@RalfJung`
Rollup of 16 pull requests Successful merges: - rust-lang/rust#137494 (libstd: init(): dup() subsequent /dev/nulls instead of opening them again) - rust-lang/rust#144541 (c-variadic: multiple ABIs in the same program for arm) - rust-lang/rust#144613 (aarch64-nintendo-switch-freestanding - Enable CPU features that are always available in a live system (crypto instructions, plus explicit NEON).) - rust-lang/rust#144780 (Add a method to dump MIR in the middle of MIR building) - rust-lang/rust#145137 (Consolidate panicking functions in `slice/index.rs`) - rust-lang/rust#145507 (Refactor attribute parsing to improve ergonomics and some diagnostics) - rust-lang/rust#145604 (Gate static closures behind a parser feature) - rust-lang/rust#145648 (Add two tidy dependency checks) - rust-lang/rust#145661 (update some s390x codegen tests) - rust-lang/rust#145672 (Instantiate higher-ranked binder with erased when checking `IntoIterator` predicate for query instability) - rust-lang/rust#145689 (Migrate `panic_unwind` to use `cfg_select!`) - rust-lang/rust#145700 (Handle `ReEarlyParam` in `type_name`.) - rust-lang/rust#145703 (Remove MIPS targets from CI LLVM platforms) - rust-lang/rust#145704 (ci: don't cleanup windows disk) - rust-lang/rust#145705 (remove an `as` cast in prefetch codegen) - rust-lang/rust#145712 (Update outdated link in bound region comments) r? `@ghost` `@rustbot` modify labels: rollup
similar to #144379, but for arm, requested in #144066.
Quoting rust-lang/reference#1946 (comment)
However for c-variadic functions,
aapcsbehaves the same asC:https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#65parameter-passing
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#7the-standard-variants
I also noticed that rustc currently emit more instructions than clang for c-variadic functions on arm, see https://godbolt.org/z/hMce9rnTh. I'll fix that separately. (edit: #144549)
try-job: armhf-gnu
r? @RalfJung