CI Test

[MihaZupan]

#78660

[MihaZupan]

/azp list

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

#78660

Author:	MihaZupan
Assignees:	-
Labels:	NO-MERGE, NO-REVIEW, area-System.Net.Http
Milestone:	8.0.0

[EgorBo]

@MihaZupan any guesses from the log of your test that has just failed?
I'm currently not able to test this on an actual linux-arm64, might be in a few hours.

[MihaZupan]

The "Correct" behavior is on the left, "arm64 checked" on the right: https://www.diffchecker.com/Wuwbdju9

utf8Length=14 utf8='70, 105, 108, 101, 195, 131, 78, 97, 109, 101, 46, 98, 97, 116' -IndexOfAnyExcept length=4 // Expected+IndexOfAnyExcept length=5 // Arm64 checked

The IndexOfAnyExcept in this case is

privatestaticreadonlyIndexOfAnyValues<byte>s_rfc5987AttrBytes=IndexOfAnyValues.Create("!#$&+-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ^_`abcdefghijklmnopqrstuvwxyz|~"u8);utf8.IndexOfAnyExcept(s_rfc5987AttrBytes);

I've added a log to see if the type of s_rfc5987AttrBytes is the expected IndexOfAnyAsciiCharValues.

[MihaZupan]

Narrowing it down to

[Fact]publicvoidIndexOfAnyExceptTest(){ReadOnlySpan<byte>bytes=newbyte[]{70,105,108,101,195,131,78,97,109,101,46,98,97,116};intoffset=bytes.IndexOfAnyExcept(s_rfc5987AttrBytes);_output.WriteLine($"s_rfc5987AttrBytes is {s_rfc5987AttrBytes.GetType().FullName}");Assert.Equal(4,offset);}

[EgorBo]

@MihaZupan from what I see so far - it reproduces on Release too (osx-arm64) and with JitMinOpts=1 meaning that it's very unlikely a jit optimization

[MihaZupan]

🤦‍♂️ Found it... it's a bug in IndexOfAnyAsciiSearcher on arm64 for ASCII byte inputs:

runtime/src/libraries/System.Private.CoreLib/src/System/IndexOfAnyValues/IndexOfAnyAsciiSearcher.cs

Line 527 in 167b0a1

if(TOptimizations.NeedleContainsZero)

should be

if(AdvSimd.Arm64.IsSupported||TOptimizations.NeedleContainsZero)

like it is above for chars

runtime/src/libraries/System.Private.CoreLib/src/System/IndexOfAnyValues/IndexOfAnyAsciiSearcher.cs

Line 506 in 167b0a1

if(AdvSimd.Arm64.IsSupported||TOptimizations.NeedleContainsZero)

I'm very surprised the tests missed this in #78093, looks like we need more ...

[EgorBo]

@MihaZupan any idea why tests in #78093 didn't fail? From my understanding, it should reliably fail on any arm64 device (since neon is always there)

[MihaZupan]

As long as it supports AdvSimd.Arm64, we should see it yeah.

I expected that at least the outerloop tests I added in that PR should exercise this case, but maybe I was wrong.
You essentially need the following:

1. You must be using the byte overloads
2. The needle passed to IndexOfAnyValues.Create must be all ASCII
3. The input you are searching must contain a non-ascii character
4. That non-ascii character must be present before any other matching character
5. Run on a machine where AdvSimd.Arm64.IsSupported

Perhaps the test doesn't satisfy 4.? I'll have to double-check.

[EgorBo]

Run on a machine where AdvSimd.Arm64.IsSupported

It should be a baseline for any arm64 hardware, unless explicitly disabled

[MihaZupan]

Actually, there is another condition:
6. The non-ASCII character that was a false-positive (or false-negative in case of Except) must be exactly 128 higher than a value present in the needle.

In this case we weren't matching 195, which happens to be 128 + 67, and 67 is the ASCII C character present in the needle.

Since we're testing random inputs, I bet this is a case we just didn't hit :/

We just got lucky that that one HTTP test happened to be using exactly such values.

[MihaZupan]

I'll get a PR up, shouldn't need this one anymore.

Thanks for looking into this as well Egor!