Repository navigation
[spec] Fix array.copy getting stuck on arrays of reference type - #2306
Merged
Merged
Conversation
Member
|
@sanguineman, I'm afraid you need to join the CG to pass the IPC check. |
Contributor
Author
|
@rossberg, thanks for the heads-up. I've joined the CG, and it passes the check now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
array.copyreduces to a sequence ofarray.getandarray.setinstructions. The reduction rules determine the optional signedness annotationsx?ofarray.getfrom the source element type, using the auxiliary function$sx:However,
$sxonly has cases for constant types and packed types:Since
storagetype = valtype | packtype,$sxis undefined for reference types. Therefore, when the source array has a reference element type andn > 0, neitherStep_read/array.copy-lenorStep_read/array.copy-gtapplies, and no otherarray.copyrule applies either. Execution gets stuck.For example, the following module is valid, since
Instr_ok/array.copyonly requires the source element type to be a subtype of the destination element type:The OCaml reference interpreter runs it as expected, because it passes no sign extension for any non-packed element type:
The SpecTec interpreter, on the other hand, fails in
$sx:This case was not caught because
test/core/gc/array_copy.wastonly executesarray.copyoni8arrays. Arrays of reference type appear only inassert_invalidmodules.Fix
This PR replaces the
consttypeclause of$sxwith avaltypeclause, so that$sxreturnsepsfor every non-packed storage type, including reference types:This is consistent with
Instr_ok/array.get, which requiressx? =/= eps <=> $is_packtype(zt).The change is applied to both
wasm-3.0andwasm-latest, and the SpecTec test expectations are updated accordingly.A regression test copies an
i31refarray, covering bothStep_read/array.copy-leandStep_read/array.copy-gt.Testing
make -C interpreter test/gc/array_copycd spectec && dune runtest test-frontend test-middlend test-latex test-prose test-splicespectec/spectec specification/wasm-3.0/*.spectec --interpreter test/core/gc/array_copy.wast(fails at the new test before this change, passes after)