-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
machinst x64: investigate remaining test failures #2079
Comments
@bnjbvr Hi .. How do you test to see all the failures? If you run:
or under the cranelift project:
you see failures I believe related to the first bullet on stack onwinding .. but those are the only ones I can see fail. |
A commit has now landed in CI with the right command line to use for running all the test cases; it's a bit long and requires Rust nightly (because of the way Cargo feature unification works in stable vs nightly):
|
Thanks ... see this now after updating the version of nightly. Did not see any errors but will take a closer look at the tests that are disabled. |
Subscribe to Label Actioncc @bnjbvr
This issue or pull request has been labeled: "cranelift"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
Some of the test failures tracked by bytecodealliance#2079 are in unwind tests that are specific to the old x86 backend: namely, these tests invoke the unwind implementation that is paired with the old backend, rather than generic over all backends. It thus doesn't make sense to try to run these tests with the new backend. (The new backend's unwind code should have analogous tests written/ported over eventually.) It seems that we were actually building *both* x86 backends when the `x64` feature was enabled, except that the old x86 backend would never be instantiated by the usual ISA-lookup logic because a `x86-64` target triple unconditionally resolves to the new one. This PR resolves both of the issues by tweaking the feature-config directives to exclude the `x86` backend when `x64` is enabled.
Some of the test failures tracked by #2079 are in unwind tests that are specific to the old x86 backend: namely, these tests invoke the unwind implementation that is paired with the old backend, rather than generic over all backends. It thus doesn't make sense to try to run these tests with the new backend. (The new backend's unwind code should have analogous tests written/ported over eventually.) It seems that we were actually building *both* x86 backends when the `x64` feature was enabled, except that the old x86 backend would never be instantiated by the usual ISA-lookup logic because a `x86-64` target triple unconditionally resolves to the new one. This PR resolves both of the issues by tweaking the feature-config directives to exclude the `x86` backend when `x64` is enabled.
This is done.
Is this done? |
I think so; we don't have any excluded GC tests anymore. |
Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:
The text was updated successfully, but these errors were encountered: