Incorrect SPIR-V generated, but no errors

[martty]

Hello,

I am having a problem where glslangValidator produces a SPIRV binary that is then rejected both by validation layers and spirv-val (also crashes in the driver).

Glslang Version: 10:11.0.0
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 11.0.0
GLSL Version: 4.60 glslang Khronos. 11.0.0
SPIR-V Version 0x00010500, Revision 3
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 10
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100

I have reduced the test case to the following (compiled as glslangValidator.exe -V --target-env vulkan1.1 .\bork_test.frag -o bork.spv):

#version 460 core
#pragma shader_stage(fragment)
#extension GL_EXT_nonuniform_qualifier: require

struct Texture_2D_Depth {
	uint value;
};

const Texture_2D_Depth builtin_shadow_map = Texture_2D_Depth(0);
layout(binding = 0, set = 1) uniform sampler2DShadow[] textures_2D_depth;
sampler2DShadow to_sampler(Texture_2D_Depth tx) {
    return textures_2D_depth[tx.value];
}

vec3 foo(sampler2DShadow s){
	return vec3(0);
}

void main() {
    vec3 x = vec3(foo(to_sampler(builtin_shadow_map)));
}

spirv-val reports:

error: line 51: OpFunctionCall Argument <id> '43[%43]'s type does not match Function <id> '16[%_ptr_UniformConstant_11]'s parameter type.
  %44 = OpFunctionCall %v3float %foo_sS21_ %43

[johnkslang]

This essentially requires GLSL to support returning a reference to sampler. My first guess is this unusual pattern is an oversight in both the specification and the front end.

At first look, maybe the specification is not clear on this. It does however say:

... Except for array indexing, structure member selection, and parentheses, opaque variables are not allowed to be operands in expressions; such use results in a compile-time error.

Opaque variables cannot be treated as l-values; hence cannot be used as out or inout function parameters, nor can they be assigned into. Any such use results in a compile-time error. However, they can be passed as in parameters with matching types and memory qualifiers. ...

The return value from a function is much like an out parameter, and should also be excluded in this list of exclusions.

If this is not clear in the specification, I recommend opening a bug against the GLSL. But, it does seem covered by you using return expression and the rule "are not allowed to be operands in experssions".

I think glslang simply needs an extra test on the function-return declaration type.

[arcady-lunarg]

This now returns an error as of 16526fd9d2fdff115451d2dbaa8436ad06707fa5, requiring the GL_ARB_bindless_texture, enabling which causes glslangValidator to refuse to generate SPIR-V.