Open taniwha opened 1 month ago
What semantics are you expecting from this GLSL? Just going by SPIR-V semantics, it seems like this shouldn't be legal, as you are giving a specialization constant a default value that's not a simple constant, which SPIR-V does not support.
The GLSL spec does say
Initializers for const declarations must be constant expressions, as defined in section 4.3.3 “Constant Expressions."
And the GL_KHR_vulkan_glsl
spec says
An expression formed with specialization constants also behaves in the shader like a specialization constant, not a like a constant.
So it seems like the logical thing would be for glslang to prohibit this type of expression.
What semantics are you expecting from this GLSL? Just going by SPIR-V semantics, it seems like this shouldn't be legal, as you are giving a specialization constant a default value that's not a simple constant, which SPIR-V does not support.
My only expectation is consistency between the tools. And maybe less reading between the lines in the specs, but that is probably for a separate issue or two.
I ran into the problem due to implementing SPIR-V in my compiler. I'd written such code as a test (to confirm my understanding of the specifications) and because glslang accepted it, I assumed it was OK (I didn't think to run its output through spirv-val), but when my own compiler's output failed, I went back to glslang to see what I had done and discovered it too failed. After rereading the relevant parts of both specs (GLSL doesn't seem to be explicit about requiring a literal) I decided to file the issue against glslang.
So it seems like the logical thing would be for glslang to prohibit this type of expression.
I agree. I did this in my compiler as it seemed I was asking the impossible from SPIR-V.
Both glslang and glslangValidator compile the following code without any diagnostics
And produce
but spirv-val produces the following error:
The spec (2.12) does seem to indicate that spirv-val is correct and glslanValidator is producing incorrect code.