[ci-scan] Skip SpanDestinationFunctions_ValueRange on iOS (refs #129045)

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.

[github-actions]

Reasoning

The SpanDestinationFunctions_ValueRange tests in DoubleGenericTensorPrimitives and SingleGenericTensorPrimitives fail on iossimulator-arm64 because the vectorized Tan implementation produces values with reduced precision compared to the scalar reference on this platform. The [ActiveIssue] attribute with PlatformDetection.IsiOS is the narrowest practical scope since the precision mismatch is platform-level and affects the Theory's multiple MemberData cases.

Linked KBE: #129045

Match verification (from Step 4.8):

1. Same test/family: yes - SpanDestinationFunctions_ValueRange is the failing test method
2. Same failure signature: yes - Assert.All() Failure with Values differ for Tan on iOS
3. Same OS: yes - iossimulator (iOS)
4. Same architecture: yes - arm64

Impact on platforms

• runtime-extra-platforms (def 154) / iossimulator-arm64 Release AllSubsets_CoreCLR / Helix queue: ubuntu.2204.armarch.open.ios / exit code 1

Errors log

[FAIL] System.Numerics.Tensors.Tests.DoubleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Double](...) }, ...)
Assert.All() Failure: 123 out of 201 items in the collection did not pass.
Error: Assert.Equal() Failure: Values differ
Expected: 0.4103212990482421
Actual: 0.41032129904823794
[FAIL] System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_ValueRange(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void Tan[Single](...) }, ...)
Assert.All() Failure: 153 out of 201 items in the collection did not pass.

First build it occurred

• Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1449088
• Finished: 2026-06-04T09:47:08Z
• Occurrences in window: 3 (builds 1449088, 1450787, 1452386)
• Computed within the scanned window; may not be the true origin.

Linked issue

#129045

---

Filed by ci-failure-scan, which scans dnceng-public outer-loop pipelines on main and converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125436search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #56073search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
github:
min-integrity: approved # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 51.3M · ◷

[dotnet-policy-service]

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

[kotlarmilos]

Closing in favor of #129235. This PR re-adds an iOS-only [ActiveIssue], which re-masks the test (reverting the pre-#128408 state) and leaves the same vectorized-Tan precision gap latent on the other ARM64 legs (android-arm64, linux-arm64, osx-arm64).

#129235 addresses the root cause: the tolerance gate IsFmaSupported returns true on ARM64 (via AdvSimd.Arm64), so the test demands x86-FMA-level precision the ARM64 path cannot meet. Switching the gate to Fma.IsSupported applies the relaxed tolerance across all ARM64 platforms while keeping coverage. Tracking the fix there.