Clang::CodeGenSPIRV test for attribute.domain.isoline.hlsl is failing on ARM64 Release on Windows

[hekota]

Description Clang::CodeGenSPIRV test for attribute.domain.isoline.hlsl is failing on ARM64 Release on Windows

Steps to Reproduce hctbuild -spirv -arm64 -Release hcttest -spirv -arm64 on ARM64 machine such as Surface Pro.

Actual Behavior

FAIL: Clang :: CodeGenSPIRV/attribute.domain.isoline.hlsl (10 of 1986)
******************** TEST 'Clang :: CodeGenSPIRV/attribute.domain.isoline.hlsl' FAILED ********************
Script:
--
C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\dxc.EXE -T hs_6_0 -E SubDToBezierHS -fcgl  C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl -spirv | C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\FileCheck.EXE C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl
--
Exit Code: 2147500037

Command Output (stdout):
--
Command 0: "C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\dxc.EXE" "-T" "hs_6_0" "-E" "SubDToBezierHS" "-fcgl" "C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl" "-spirv"
Command 0 Result: 2147500037
Command 0 Output:


Command 0 Stderr:
fatal error: generated SPIR-V is invalid: ControlBarrier: Memory Semantics can have at most one of the following bits set: Acquire, Release, AcquireRelease or SequentiallyConsistent

  OpControlBarrier %uint_2 %uint_4 %uint_0



note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible





Command 1: "C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\FileCheck.EXE" "C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl"
Command 1 Result: 2
Command 1 Output:


Command 1 Stderr:
FileCheck error: '-' is empty.

Environment DXC version: main as of 1/22/2024 Surface Pro, Windows 11 (26016.1001, arm64)

[s-perron]

This is odd. The instruction is correct. The memory semantics is %uint_0, which means none of the semantics are set. I looked at the code in the validator, and it looks correct as well. I'm wondering if there was a miscompilation somewhere.

We'll have to see if we can get access to a windows arm device. We generally do not have those immediately available to us.