Setting COMPlus_EnableHWIntrinsic=0 causes System.PlatformNotSupportedException with optimized libraries code #60035
Comments
dotnet-issue-labeler
bot
added
the
untriaged
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
@tannergooding I wonder why we take @davidwrighton Do we have special handling for |
@echesakovMSFT There was a regression at one point where I don't think we have any tests that explicitly check that setting the environment variable correctly controls the |
|
I know we discussed this in the past but I don’t know where we ended up. Do we test anything but AVX paths in the libraries (on x64)? And where we have added intrinsic paths for Arm64, do we test the software fallback paths? Just wondering how large the test gap might be. |
I know we have tests in the runtime side to test every ISA configuration (just not that the environment variables themselves are doing the right thing). I don't know where we landed with the libraries jobs alsoo running with those switches.... |
I don't see relevant DOTNET_ or COMPLUS_ in our yml, so I guess we have a test hole: we are shipping code we never test? Should we drive plugging that somehow before 7.0 feature coding starts, do you think? cc @safern |
It was tested in all the various configurations a couple times, I just don't know/believe we have the infra to do it automatically right now. |
|
You’re quite right: I should have said that we do not test in automation. We have other such areas eg DirectoryServices tests need Docker containers. But this one seems feasible as it’s susceptible to environment variables. Could we safely pairwise this into our matrix perhaps eg Server 2022 always has AVX paths disabled? |
|
I think we should be able to yes, especially as an outerloop. We just need to define the jobs and ensure the right environment variables are set. I can sync with Santi or someone else tomorrow and figure this out. |
|
Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics Issue DetailsWhile working on #38162 I observed behavior (that I believe is incorrect) when running with .NET 6 SDK RC1. To reproduce the issue build and run the project using the following sequence of commands: Runtime_60035.csproj <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
</Project>Runtime_60035.cs using System;
using System.Text;
using System.Text.Encodings.Web;
namespace Runtime_60035
{
class Program
{
static void Main(string[] args)
{
byte[] inputBytes = Encoding.UTF8.GetBytes("https://github.com/dotnet/runtime");
Console.WriteLine(UrlEncoder.Default.FindFirstCharacterToEncodeUtf8(inputBytes));
}
}
}The result will be a failure with the following stack trace If in addition to setting
|
|
@davidwrighton I am confirming (via the test #60047 I am working on) that the behavior is interaction between a crossgen2-d image and the crossgen2 assumes that |
|
I think we could request the dnceng team to setup a helix queue that has avx disabled or we already have support (this was added to run jit stress tests) to submit test runs with different |
|
I fear we have hijacked this issue 😄 moving to #950 |
|
Here is how it should work:
@echesakovMSFT Where do you see this breaking? |
|
The problem seems to be that the env variables like We need to move reading of these env variables to the VM. |
@jkotas I found this accidentally when I forgot to unset
I am working on the test to make sure that this functionality is properly validated in the CI. |
jeffhandley
removed
the
untriaged
|
I'm not certain if this is the same issue, but I encountered something similar with In simple terms, I'm using a matrix in GitHub actions to run my unit test suite against various hardware situations in order to ensure that my fallback logic when the intrinsic is not supported is accurate. It appears that when This works fine with the .NET 5 SDK, so it seems like a regression to me. However, there is a pretty easy workaround for this specific scenario. For me, the workaround is to run - name: Install dependencies
run: dotnet restore
- name: Build dependencies
run: dotnet build --configuration Release --verbosity normal
- name: Test
run: |
export COMPlus_Enable${{ matrix.disable }}=0 && \
dotnet test --no-build -f ${{ matrix.framework }} --configuration Release --verbosity normal --logger "trx;LogFileName=results.trx" |
|
@brantburnett I believe this is a occurrence of the same issue. |
ghost
added
the
in-pr
…onfig switches (#62420) * Adding a regression test for #60035 * Add the correct "ISA implications" for Vector64/128 * Moving the `COMPlus_Enable*` HWIntrinsic ISA switches to the VM * Ensure Set64BitInstructionSetVariants is called before EnsureValidInstructionSetSupport * Ensure opts.compSupportsISA isn't overwritten to 0 * Ensure that Lzcnt is dependent on X86Base and AvxVnni is dependent on Avx2 * Adding x64, x86, and Arm64 specific views to help with debugging CorInfoInstructionSet * Keep the JIT in charge of "artificial" ISAs * Update JitBlue/Runtime_34587 to also validate the xplat SIMD types
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
While working on #38162 I observed behavior (that I believe is incorrect) when running with .NET 6 SDK RC1.
To reproduce the issue build and run the project using the following sequence of commands:
Runtime_60035.csproj
Runtime_60035.cs
The result will be a failure with the following stack trace
If in addition to setting
COMPlus_EnableHWIntrinsic=0I setCOMPlus_ReadyToRun=0the issue goes away.The text was updated successfully, but these errors were encountered: