-
Notifications
You must be signed in to change notification settings - Fork 13.6k
test using multiple c-variadic ABIs in the same program #144379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test using multiple c-variadic ABIs in the same program #144379
Conversation
@bors2 try |
…bis, r=<try> test using multiple c-variadic ABIs in the same program try-job: `x86_64-*`
💔 Test failed (CI). Failed job:
|
This comment has been minimized.
This comment has been minimized.
@bors2 try |
…bis, r=<try> test using multiple c-variadic ABIs in the same program try-job: `x86_64-gnu` try-job: `x86_64-msvc-*`
Ah, that's a fun way of testing this. Could you add the C source code for that assembly in the test file, so we have it checked in to git? |
596d8e8
to
aea74c4
Compare
aea74c4
to
963cd8a
Compare
I know nothing about these ABIs or issues with it, @workingjubilee do you want to take this one? |
I was about to approve -- I don't know how the ABIs are implemented, but the way this is being tested looks sound to me. |
Ah cool, that wfm |
Let's land this then, we can always adjust later if @workingjubilee has more comments. It's just a test after all. @bors r+ rollup |
…-multiple-abis, r=RalfJung test using multiple c-variadic ABIs in the same program tracking issue: rust-lang#100189 Check that multiple c-variadic calling conventions can be used in the same program. Clang and gcc reject defining functions with a non-default calling convention and a variable argument list, so C programs that use multiple c-variadic calling conventions are unlikely to come up. Here we validate that our codegen backends do in fact generate correct code. (CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows) try-job: `x86_64-gnu` try-job: `x86_64-msvc-*`
Rollup of 13 pull requests Successful merges: - #144356 (Add `ignore-backends` annotations in failing GCC backend ui tests) - #144359 (add codegen test for variadics) - #144376 (Suggest unwrapping when private method name is available in inner type) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144412 (Small cleanup: Use LocalKey<Cell> methods more) - #144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144424 (Allow setting `release-blog-post` label with rustbot) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144435 (rustc-dev-guide subtree update) - #144445 (Fix `./x check bootstrap` (again)) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 13 pull requests Successful merges: - #144356 (Add `ignore-backends` annotations in failing GCC backend ui tests) - #144359 (add codegen test for variadics) - #144376 (Suggest unwrapping when private method name is available in inner type) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144412 (Small cleanup: Use LocalKey<Cell> methods more) - #144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144424 (Allow setting `release-blog-post` label with rustbot) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144435 (rustc-dev-guide subtree update) - #144445 (Fix `./x check bootstrap` (again)) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 13 pull requests Successful merges: - #144356 (Add `ignore-backends` annotations in failing GCC backend ui tests) - #144359 (add codegen test for variadics) - #144376 (Suggest unwrapping when private method name is available in inner type) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144412 (Small cleanup: Use LocalKey<Cell> methods more) - #144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144424 (Allow setting `release-blog-post` label with rustbot) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144435 (rustc-dev-guide subtree update) - #144445 (Fix `./x check bootstrap` (again)) r? `@ghost` `@rustbot` modify labels: rollup
…-multiple-abis, r=RalfJung test using multiple c-variadic ABIs in the same program tracking issue: rust-lang#100189 Check that multiple c-variadic calling conventions can be used in the same program. Clang and gcc reject defining functions with a non-default calling convention and a variable argument list, so C programs that use multiple c-variadic calling conventions are unlikely to come up. Here we validate that our codegen backends do in fact generate correct code. (CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows) try-job: `x86_64-gnu` try-job: `x86_64-msvc-*`
Rollup of 14 pull requests Successful merges: - #144316 (bootstrap: Move musl-root fallback out of sanity check) - #144352 (RustWrapper: Suppress getNextNonDebugInfoInstruction) - #144356 (Add `ignore-backends` annotations in failing GCC backend ui tests) - #144359 (add codegen test for variadics) - #144376 (Suggest unwrapping when private method name is available in inner type) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144412 (Small cleanup: Use LocalKey<Cell> methods more) - #144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144424 (Allow setting `release-blog-post` label with rustbot) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144435 (rustc-dev-guide subtree update) - #144445 (Fix `./x check bootstrap` (again)) r? `@ghost` `@rustbot` modify labels: rollup
Failed in rollup: #144466 (comment)
@bors r- |
963cd8a
to
69ebf70
Compare
Of course it's macos symbol mangling Usually the way to resolve this sort of problem is to use a naked function, but those can't yet use @bors2 try |
…bis, r=<try> test using multiple c-variadic ABIs in the same program try-job: `x86_64-gnu` try-job: `x86_64-msvc-*` try-job: `x86_64-apple-2`
@bors r=RalfJung |
…-multiple-abis, r=RalfJung test using multiple c-variadic ABIs in the same program tracking issue: rust-lang#100189 Check that multiple c-variadic calling conventions can be used in the same program. Clang and gcc reject defining functions with a non-default calling convention and a variable argument list, so C programs that use multiple c-variadic calling conventions are unlikely to come up. Here we validate that our codegen backends do in fact generate correct code. (CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows) try-job: `x86_64-gnu` try-job: `x86_64-msvc-*` try-job: `x86_64-apple-2`
Rollup of 13 pull requests Successful merges: - #144359 (add codegen test for variadics) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144429 (Enable outline-atomics for aarch64-unknown-linux-musl) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144464 (Only run bootstrap tests in `x test` on CI) - #144470 (clif: Don't set the `compiler-builtins-no-f16-f128` feature) - #144480 (Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen") - #144495 (bump cargo_metadata) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 13 pull requests Successful merges: - #141840 (If `HOME` is empty, use the fallback instead) - #144359 (add codegen test for variadics) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144429 (Enable outline-atomics for aarch64-unknown-linux-musl) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144464 (Only run bootstrap tests in `x test` on CI) - #144470 (clif: Don't set the `compiler-builtins-no-f16-f128` feature) - #144480 (Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen") r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #144379 - folkertdev:c-variadic-same-program-multiple-abis, r=RalfJung test using multiple c-variadic ABIs in the same program tracking issue: #100189 Check that multiple c-variadic calling conventions can be used in the same program. Clang and gcc reject defining functions with a non-default calling convention and a variable argument list, so C programs that use multiple c-variadic calling conventions are unlikely to come up. Here we validate that our codegen backends do in fact generate correct code. (CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows) try-job: `x86_64-gnu` try-job: `x86_64-msvc-*` try-job: `x86_64-apple-2`
tracking issue: #100189
Check that multiple c-variadic calling conventions can be used in the same program.
Clang and gcc reject defining functions with a non-default calling convention and a variable
argument list, so C programs that use multiple c-variadic calling conventions are unlikely
to come up. Here we validate that our codegen backends do in fact generate correct code.
(CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows)
try-job:
x86_64-gnu
try-job:
x86_64-msvc-*
try-job:
x86_64-apple-2