[maleadt]

The Windows intel_cpu CI job started crashing in intel/gpuarrays/reductions/sum prod (#565's run, and the merge commit's run on main): an access violation inside intelocl64.dll during clBuildProgram. It is not caused by #565, which doesn't change the device code: the pre-PR commit d2b2f1f crashes the same way locally (Linux, Ryzen 9950X) and in a Windows VM, and the crash is deterministic for the kernel at fault. Minimal reproducer:

using intel_opencl_rt_jll, OpenCL
A, B = CLArray(rand(Complex{Int16}, 10, 10)), CLArray(rand(Complex{Int16}, 10, 10))
mapreduce(*, +, A, B)

1.	Running pass "vpo-directive-cleanup" on function "_Z21gpu__mapreduce_block_..."
2.	Running pass "SimplifyCFGPass<...>" on function "_Z21gpu__mapreduce_block_..."
signal 11 (1): Segmentation fault
_ZN4llvm7PHINode19removeIncomingValueEjb at libintelocl.so

That's the crash from #559 (SimplifyCFG under Intel's vpo-directive-cleanup, on a reduction over two arrays broadcast together), reached through the @inferred mapreduce(*, +, A, B) check at the end of the sum prod testsuite. The crash doesn't depend on the requested sub-group size (none, 8, 16 or 32 all crash), the TBB worker count, or the allocator; it does depend on the host: here Complex{Int16} 10×10 and ComplexF32 10×10×10 crash while the real types don't, and the CI runners (EPYC 7763, no AVX-512) crash on other kernels of the same test (prod! through AcceleratedKernels' 1D mapreduce, an Int16 3D reduction in a VM on this host) and passed the Linux job. That host dependence is why the job used to pass.

This skips gpuarrays/reductions/sum prod on the Intel CPU runtime, alongside the five GPUArrays tests already skipped for #558/#559. Both crashes are now reported upstream with reduced standalone SPIR-V reproducers: intel/llvm#23517 (#558) and intel/llvm#23518 (#559, including this kernel).