Jim Blandy

@TobTobXX Would you be able to put together a reduced version of the test case, based on the loop at line 209?

> I think a simple example would be an explicit `vector_4[4]`. I think this might be a limitation in DXBC or FXC where it doesn't allow non-constant indexing into vectors....

But, for example, Naga validates this and I suspect the HLSL compiler will reject it: ``` fn f(v: vec4) -> f32 { var sum: f32 = 0.0; for (var i...

Unless @kvark has some clever way out for us, I think that leaves us at > If that's what's going on, then Naga may just have to accept that HLSL...

> Implementing the OOB behavior above would fix the issue. The OOB behavior is already implemented, actually. We're just being over-eager about detecting errors at compile time.

Yes, with `let` I get: ``` error: Index 9 is out of bounds for expression [2] ``` This is Naga's fault: it's reporting as a compile-time error a problem that...

Out-of-bounds handling is implemented for both buffers and textures on HLSL, Vulkan, and MSL, and on WGSL by pass-through. GLSL is still needed, but OpenGL can't fully support `wgpu`, so...

If implementing WGSL's division semantics happens to work around this FXC bug, that'd be great. The Naga HLSL back end code implementing the workaround should mention this FXC bug, so...

See also #1648.

This still needs to be implemented.