Skip to content

Conversation

@alexcrichton
Copy link
Member

This commit fixes some more fallout found on oss-fuzz about the x64 generating rounding builtins when it shouldn't be. This situation is caused by simd float rounding instructions which the x64 backend lowers to libcall-per-element and now needs to move that logic to the frontend instead.

This commit fixes some more fallout found on oss-fuzz about the x64
generating rounding builtins when it shouldn't be. This situation is
caused by simd float rounding instructions which the x64 backend lowers
to libcall-per-element and now needs to move that logic to the frontend
instead.
@alexcrichton alexcrichton requested a review from a team as a code owner April 30, 2025 16:23
@alexcrichton alexcrichton requested review from dicej and removed request for a team April 30, 2025 16:23
@alexcrichton
Copy link
Member Author

cc @sunfishcode

Copy link
Contributor

@dicej dicej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have enough Cranelift context yet to evaluate this properly, so I'll let Dan review it before approving, but LGTM.

@alexcrichton
Copy link
Member Author

@fitzgen would you be able to take a look at this perhaps?

@fitzgen fitzgen added this pull request to the merge queue May 5, 2025
Merged via the queue into bytecodealliance:main with commit 33c1002 May 5, 2025
41 checks passed
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 6, 2025
This commit is similar to bytecodealliance#10699, another instance of a libcall popping
up late in the x64 backend. Fuzzing found this issue and to help verify
this is the last one I've run the whole `*.wast` test suite with the
x86_64 baseline (no target features) and saw the panic before this PR
and no more panics after.
github-merge-queue bot pushed a commit that referenced this pull request May 6, 2025
This commit is similar to #10699, another instance of a libcall popping
up late in the x64 backend. Fuzzing found this issue and to help verify
this is the last one I've run the whole `*.wast` test suite with the
x86_64 baseline (no target features) and saw the panic before this PR
and no more panics after.
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 7, 2025
This commit fixes some more fallout found on oss-fuzz about the x64
generating rounding builtins when it shouldn't be. This situation is
caused by simd float rounding instructions which the x64 backend lowers
to libcall-per-element and now needs to move that logic to the frontend
instead.
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 7, 2025
This commit is similar to bytecodealliance#10699, another instance of a libcall popping
up late in the x64 backend. Fuzzing found this issue and to help verify
this is the last one I've run the whole `*.wast` test suite with the
x86_64 baseline (no target features) and saw the panic before this PR
and no more panics after.
alexcrichton added a commit that referenced this pull request May 7, 2025
* Skip a test with threads on ASAN (#10728)

It's expected that this has memory leaks, there's no clean shutdown in
the CLI right now.

* Fix missing libcalls with simd float rounding (#10699)

This commit fixes some more fallout found on oss-fuzz about the x64
generating rounding builtins when it shouldn't be. This situation is
caused by simd float rounding instructions which the x64 backend lowers
to libcall-per-element and now needs to move that logic to the frontend
instead.

* Fix another libcall popping up with simd (#10735)

This commit is similar to #10699, another instance of a libcall popping
up late in the x64 backend. Fuzzing found this issue and to help verify
this is the last one I've run the whole `*.wast` test suite with the
x86_64 baseline (no target features) and saw the panic before this PR
and no more panics after.

* Inline assembler-x64 `generated_files` in `main.rs` (#10739)

The public function `generated_files` in `cranelift-assembler-x64` makes
the generated `rlib` non-deterministic because it contains the full
paths of generated files. But this function is only used in `main.rs` of
the same crate, so this change inlines it there to keep the library artifact
deterministic while maintaining the same behavior.

---------

Co-authored-by: Adam Bratschi-Kaye <adam.bratschikaye@dfinity.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants