Repository navigation
compiler destructive update: Fix crash caused by patch order - #9909
Conversation
lucioleKi
added
team:VM
CT Test Results 2 files 333 suites 8m 39s ⏱️ Results for commit d470827. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts
// Erlang/OTP Github Action Bot |
| {tuple_elements,[{IA,EA}|Es]}; | ||
| merge_patches({tuple_elements,Es}, {tuple_element,IA,EA,_}) -> | ||
| {tuple_elements,[{IA,EA}|Es]}; | ||
| merge_patches(Patch, {self,heap_tuple}) -> |
There was a problem hiding this comment.
I would have incorporated @TrevorSA123's cause analysis into the commit message, and updated the comment for this clause and the next. The important part being that we want the merge to be commutative with respect to {self,heap_tuple} and that as soon as we find something that's more specific, the more specific patch subsumes the {self,heap_tuple}.
There was a problem hiding this comment.
LGTM with the updated patch, comment resolved.
Fix erlang#9903. In `beam_ssa_destructive_update:patch_is/5`, OTP 28 uses `lists:splitwith/2`, which may deliver a patch list where a more specific patch is placed before a less specific patch. Therefore, in the later `merge_patches/2`, the merging logic needs to be commutative and takes care of all possible orders of patches.
b477503 to
d470827
Compare
3 participants
Fix #9903