[RISC-V] Reverse changes from PR#111887 for riscv64 architecture

[sirntar]

We haven't added support for vararg on riscv64 yet. Removing tests that needs vararg support from exclusion list (#111887) won't make them work, it will just show us more failures, that are related to unsupported functions.
When we add vararg support, we will re-enable these tests.

Before:

Time [secs] | Total | Passed | Failed | Skipped | Assembly Execution Summary
============================================================================
   6108.572 | 14893 |  14811 |     28 |      54 | (total)

After:

Time [secs] | Total | Passed | Failed | Skipped | Assembly Execution Summary
============================================================================
   6061.472 | 14456 |  14397 |      9 |      50 | (total)

Part of #84834, cc @dotnet/samsung

[risc-vv]

RISC-V Release-CLR-QEMU: 9451 / 9495 (99.54%)

=======================
      passed: 9451
      failed: 29
     skipped: 134
      killed: 15
------------------------
  TOTAL libs: 9629
 TOTAL tests: 9629
   REAL time: 58min 15s 960ms
=======================

Release-CLR-QEMU.md, Release-CLR-QEMU.xml, testclr_output.tar.gz

RISC-V Release-FX-QEMU: 0 / 259 (0.00%)

=======================
      passed: 0
      failed: 0
     skipped: 0
      killed: 259
------------------------
  TOTAL libs: 259
 TOTAL tests: 259
   REAL time: 42s 973ms
=======================

Release-FX-QEMU.md, Release-FX-QEMU.xml, testfx_output.tar.gz

Build information and commands

GIT: dca0958c4a4ab112b803fe6fcb25645703e1e808
CI: 91ac750ef88804d9fd46af0db604953a48c5f8d1
REPO: dotnet/runtime
BRANCH: main
CONFIG: Release
LIB_CONFIG: Release

[filipnavara]

The tests are supposed to be disabled by different mechanism:

runtime/src/tests/JIT/jit64/jit64_2.csproj

Lines 2 to 4 in d9b7515

	<PropertyGroup>
	<CLRTestTargetUnsupported Condition="'$(TargetsWindows)' != 'true'">true</CLRTestTargetUnsupported>
	</PropertyGroup>

I wonder why that doesn't work for your use case.

[sirntar]

I wonder why that doesn't work for your use case.

@filipnavara That's a good question, we don't know yet, it's a temporary solution created on the fly

[sirntar]

I've run multiple tests regarding this issue and it seems that the problem lies is elsewhere. Most of the failures we are getting right now in coreclr are related to segmentation faults. Therefore I'm closing this PR.