Merged to sycl-web with no conflict or build issue

Completed successfully

sycl-web/sycl-latest-good -- 0148ccf - Mon Aug 3 11:23:34 2026 +0200
sycl-web/main-latest-good -- b2cca30 - Mon Aug 3 12:31:25 2026 +0200

Merged to sycl-web with no conflict or build issue

Build passed

[SYCL] Fix g++ host-compiler build after 31945d8 (#22849)

Fix sycl-in-tree::Complex~sycl_complex_include_order.cpp and
sycl-in-tree::Regression~fsycl-host-compiler.cpp tests that broke after
commit 31945d8 which deprecated the sampler class and access
targets.

The commit used __SYCL_DEPRECATED which unconditionally expands to
[[deprecated(...)]] on all compilers. When compiled with g++ (via
-fsycl-host-compiler=g++) versions prior to GCC 13, mixing
__attribute__((visibility("default"))) with [[deprecated(...)]] on a
class declaration causes a parse error. Use __SYCL2020_DEPRECATED
instead, which is gated on SYCL_LANGUAGE_VERSION == 202012L and matches
the pattern used by other SYCL 2020 deprecations in the same files.

Fixes: CMPLRLLVM-77354

Co-authored-by: Jinsong Ji <jinsong.ji@intel.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

[sycl-jit] Parallelize resource.cpp compile by sharding all #embed fi…

…les (#22768)

In downstream, resource.cpp #embeds ~1.5GB of SYCL headers, libclc, and
libdevice binaries into a single TU, which took ~2m13s to compile at O2.

generate.py now bin-packs all embedded files across a fixed number of
resource-shard-N.cpp translation units, leaving resource.cpp itself with
no #embeds at all.

CMPLRLLVM-77210

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

[SYCL] Fix fp4_e2m1_x2 encode/decode builtins for half and bfloat16 (#…

…22781)

Two bugs in fp4_e2m1_x2 device-side conversions:

1. Encode used ClampConvertFP16/BF16ToE2M1INTEL, removed in f0cc082
since FP4 saturation is unconditional. Renamed to the plain Convert*
form under SPV_INTEL_float4.

2. Decode passed a <2 x i8> (two extracted nibbles) to
ConvertE2M1ToFP16/BF16INTEL. The translator's packing rule treats each
i8 as two FP4 values, so <2 x i8> became <4 x Float4E2M1> and the second
element always decoded to zero. Fix by passing vals[0] as fp4_uint8_vec1
(<1 x i8>): the translator unpacks it as <2 x Float4E2M1> and emits a
single FConvert for both elements. fp4_uint8_vec1 is a distinct type
from uint8_t so the overloads can differ in return type.

Assisted-By: Claude

[SYCL] Remove undocumented descriptors (#22542)

Removal of non-standard descriptors from multiple classes

fixes #22477

[CI] Change MSVC env setup action (#22745)

Today we are using `ilammy/msvc-dev-cmd` which uses an old Node version
that is about to be removd and nobody seems to be updating it so switch
to a new one that does the same thing with a supported Node version

Nightly run (fail not related):
https://github.com/intel/llvm/actions/runs/30016154671/job/89236726985

Co-Authored-By: Claude Opus 4.8 (1M context)
[noreply@anthropic.com](mailto:noreply@anthropic.com)

Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>

[SYCL][E2E] Fix flaky DX11 interop tests (#22708)

read_write_unsampled and its semaphore variant failed
non-deterministically, mismatching at the first non-zero texel on a
varying subset of configurations. Root cause is missing D3D11-to-SYCL
synchronization in the test itself.

- Non-semaphore variant. Current incorrect sequence looks like this:
```
  AcquireSync(0); 
  UpdateSubresource(...);  // returns once the upload is queued 
  ReleaseSync(1);
  AcquireSync(1);          // succeeds: key matches last ReleaseSync
  submit_sycl_kernel();    // but the D3D GPU upload may still be running
```

`AcquireSync(1)` gives the SYCL queue no execution dependency on the
earlier upload, so the kernel could read stale/zero texels. Fixed by
waiting for the upload to complete (`D3D11_QUERY_EVENT` + `Flush`)
before SYCL uses it.

- Semaphore variant. The `ID3D11Fence` is created with initial value
`0`, so waiting for `0` is already satisfied before the D3D upload or
signal executes.

```
  // Incorrect
  fence = CreateFence(initialValue = 0);
  D3D_upload_texture();  // queued asynchronously
  D3D_signal(fence, 0);  // queued after upload, but changes 0 -> 0
  SYCL_wait(fence, 0);   // already satisfied from fence initialization
  SYCL_launch_kernel();  // may run before the upload finishes
```

Fixed by using a value the fence has not reached yet:

```
  // Correct
  fence = CreateFence(initialValue = 0);
  D3D_upload_texture();
  D3D_signal(fence, 1);  // changes 0 -> 1 only after upload completes
  SYCL_wait(fence, 1);   // cannot complete while fence is still 0
  SYCL_launch_kernel();  // runs after the upload
```

The point is not that `1` is special: it is a value the fence has not
reached yet, whereas `0` was already reached at creation.

Assisted-By: Claude