On Windows/x86, if a call returns a SIMD8 in two registers
(eax, edx), and needs to be assembled and stored into a single
SIMD register, AND we don't have the SSE41 ABI available (because
the hardware doesn't support it, or we specifically disable it),
then we need a temporary register. In the failure case, the target
register and temporary register were the same, and then interfered
with each other. The fix is to force the temporary register to
be different from the target register.

Fixes #58899

Co-authored-by: Bruce Forstall <[email protected]>

…t and test fixes for Android (#58841)

Manual backport of #57208, #58519, #58562, #58210, #57732, #58428, #58586, #58745, #57687 to release/6.0

Numerous test suites have been failing for iOS/tvOS/MacCatalyst consistently on CI without useful logs as to why. Moreover, some of these suites pass locally.

This PR looks to reduce the failures on CI by skipping the problematic suites
Skips test suites logged in #53624

ActiveIssues
#58440
#58418
#58367
#58584

Co-authored-by: Mitchell Hwang <[email protected]>
Co-authored-by: Alexander Köplinger <[email protected]>
Co-authored-by: Jo Shields <[email protected]>

…skFactory (#58917)

* [tasks] [net472] Add ProjectReferences to JsonToItemsTaskFactory

Reference the same versions of System.Threding.Tasks.Extensions and
System.Text.Json that MSBuild in Visual Studio 2022 uses.

Fixes build errors on maui-ios (and possibly blazorwasm) targets on Windows
like:

```
System.MissingMethodException: Method not found: 'System.Threading.Tasks.ValueTask`1<!!0> System.Text.Json.JsonSerializer.DeserializeAsync(System.IO.Stream, System.Text.Json.JsonSerializerOptions, System.Threading.CancellationToken)'.
   at JsonToItemsTaskFactory.JsonToItemsTaskFactory.JsonToItemsTask.<GetJsonAsync>d__24.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at JsonToItemsTaskFactory.JsonToItemsTaskFactory.JsonToItemsTask.GetJsonAsync(String jsonFilePath, FileStream file)
   at JsonToItemsTaskFactory.JsonToItemsTaskFactory.JsonToItemsTask.TryGetJson(String jsonFilePath, JsonModelRoot& json)
   at JsonToItemsTaskFactory.JsonToItemsTaskFactory.JsonToItemsTask.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at
   Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
```

from `C:\Program
Files\dotnet\packs\Microsoft.NET.Runtime.MonoTargets.Sdk\6.0.0-rc.1.21451.13\Sdk\RuntimeComponentManifest.targets`

* assembly version is 4.2.0.1, but nuget version is 4.5.4, apparently

Co-authored-by: Aleksey Kliger <[email protected]>

* NT prefix shall not be treated as a relative path

* Remove file-folder-match validation

* Use SubstituteName instead of PrintName since the latter is just for display and can be misleading

* Fix MS.IO.Redist

* Fix whitespace in Strings.resx

* Address suggestions

)

* [mini] Use alloca for runtime_invoke retval buffer

Fixes #58957
Related to #58215 which was attempting to
fix #58190

* Set initial return buffer size to TARGET_SIZEOF_VOID_P

In the common case we use the return buffer just to hold a pointer to
the return value

Co-authored-by: Aleksey Kliger <[email protected]>
Co-authored-by: Aleksey Kliger <[email protected]>

Identified deadlock between finalizer thread and rundown enumerating
all interpreter method. Since rundown will query for method name
in callback when iterating interpreter methods, interp_jit_info_foreach,
that might lead to additional loader activity. The hash map in
interpreter keeping the methods is locked with default JIT memory manager,
but since the callback might end up in mono_class_create_from_typedef
that will take loader lock, we get the following lock order on that
code path, memory manager->loader lock. Finalizer thread invokes
OnThreadExiting using interpreter and that might end up with a reverse
lock order, loader lock->memory manager on that code path, so these
two have a potential to deadlock. This is not a problem under JIT
or AOT since the JIT hash table is lock free therefore not causing
any deadlocks due to lock order between memory manager and loader lock.

Could be fixed by changing into a lock free hash table in interpreters
for interp_code_hash might be to risky at this point. A more safe fix
is to take a copy of the pointers while holding lock and then iterate
using local copy (simple array of pointers). Since this method is
only called during rundown, only when using interpreter, and only
include the pointers (InterpMethod *) we use with the callback,
it will have some temporary memory impact (allocating an array
of pointers), but will mitigate the deadlock since we can safely
call iterator callback without holding the lock. It will also
improve interpreter performance in situations where we run session
rundown, since lock will be held a much shorter amount of time.

Co-authored-by: lateralusX <[email protected]>

* Throw on unsupported types in src gen

* Misc non-functional changes and feedback

* Fix typo

* Change disallowed terminology to unsupported

Co-authored-by: Steve Harter <[email protected]>

…itional breakpoint (#58910)

Backport of #58908 to release/6.0

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1390250?src=WorkItemMention&src-action=artifact_link

…58390)

* Set generic type arguments nullability for value types

* Skip test on mono

* Apply commment

* Separate var name parts with _

* Reflection nullability API: improve test coverage, fix bug found (#58479)

* Add/remove some tests, fix generics indexing bug

Co-authored-by: Buyaa Namnan <[email protected]>