Fix wstring::find_first_of infinite loop on ARM64#6345
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes an ARM64/ARM64EC infinite loop in basic_string(_view)::find_first_of for 2-byte (and larger) element types, a regression introduced in MSVC Build Tools 14.51 (PR #6115). In the Neon bitmap worker _Impl_first_neon, the scalar tail's index advance (++_Ix;) lived at the bottom of a do/while loop, so a continue taken for haystack elements >= 256 (the _Any_of case) skipped the increment and froze the index, hanging forever. The fix moves the increment into the loop condition so it is always executed.
Changes:
- Made the scalar-tail index advance unconditional in
_Impl_first_neonby folding++_Ixinto thedo/whilecondition. - Added a targeted regression test
test_gh_6342_find_first_of()covering the large-char × matching-char combinations in the scalar tail. - Added a product-code comment linking the
_Use_bitmap_neonthreshold to the new test.
Show a summary per file
| File | Description |
|---|---|
stl/src/vector_algorithms.cpp |
Fixes the frozen index by making ++_Ix part of the do/while condition; adds a comment noting the test's dependency on the bitmap threshold. |
tests/std/tests/VSO_0000000_vector_algorithms/test.cpp |
Adds and registers test_gh_6342_find_first_of() to verify the fix and guard against regression. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 2/2 changed files
- Comments generated: 0
|
I'm mirroring this to the MSVC-internal repo. Please notify me if any further changes are pushed, otherwise no action is required. |
Fixes #6342 which is a regression in the MSVC Build Tools 14.51, so I might need to think about backporting this.
I've verified that without the fix, my cleaned-up test case triggers the infinite loop in our PR/CI system.
I enhanced the test case to cover 4 combinations: large character absent/present at a position before matching character absent/present. (This theoretically guards against behavior like "oh, large character found, immediately return
npos".) I reset the haystack to allL'x'at the end, even though those writes are dead, to make the pattern clear. I felt that this was simpler than allowing mutations to accumulate between each check, which is harder to keep track of.It's unusual for our product code comments to mention test code, but in this case because we have a performance threshold in the product code that affects whether the test code exercises something meaningful, I felt that a single-line comment was warranted.
The bugfix is intentionally minimal since I have no insight into ARM64 performance effects.
I reviewed all occurrences of
continue;and I believe this was the only damaged one.