KhronosGroup / KhronosGroup/glslang

Invalid SPIR-V can be generated: OpLoad a pointer to a OpTypeRuntimeArray

Open
#2,733 4 comments 0 reactions 0 assignees View on GitHub
bug GLSL/ESSL SPIR-V
Dominant language
C++
Stars
3.6k
Forks
989
Avg merge
1d 2h
Merged PRs (30d)
31

Description

Heya! I've minimized down a repro down to a frankly bizarre looking shader: the below generates an instruction of the form `%15 = OpLoad %_runtimearr_float %14`. This is illegal: the SPIR-V spec states, in the `OpLoad` instruction, "Result Type is the type of the loaded object. It must be a type with fixed size; i.e., it must not be, nor include, any OpTypeRuntimeArray types."

Unfortunately, [spirv-val](https://github.com/KhronosGroup/SPIRV-Tools) does not catch this case, and the resulting SPIR-V module passes spirv-val. I have [reported the bug here](https://github.com/KhronosGroup/SPIRV-Tools/issues/4472).

```glsl
#version 450
layout(binding = 0) buffer stuff {
float variable_array[];
};
void main() {
variable_array = variable_array;
}
```

Compiled via: `glslangValidator -V test.glsl.frag`. Also reproduces with [shaderc](https://github.com/google/shaderc), via `glslc test.glsl.frag -o glslc.spv` (I believe glslc uses glslang?)

Generated SPIR-V, click to expand

```spir-v
; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 10
; Bound: 17
; Schema: 0
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %main "main"
OpExecutionMode %main OriginLowerLeft
OpSource GLSL 450
OpName %main "main"
OpName %stuff "stuff"
OpMemberName %stuff 0 "variable_array"
OpName %_ ""
OpDecorate %_runtimearr_float ArrayStride 4
OpMemberDecorate %stuff 0 Offset 0
OpDecorate %stuff BufferBlock
OpDecorate %_ DescriptorSet 0
OpDecorate %_ Binding 0
%void = OpTypeVoid
%3 = OpTypeFunction %void
%float = OpTypeFloat 32
%_runtimearr_float = OpTypeRuntimeArray %float
%stuff = OpTypeStruct %_runtimearr_float
%_ptr_Uniform_stuff = OpTypePointer Uniform %stuff
%_ = OpVariable %_ptr_Uniform_stuff Uniform
%int = OpTypeInt 32 1
%int_0 = OpConstant %int 0
%_ptr_Uniform__runtimearr_float = OpTypePointer Uniform %_runtimearr_float
%main = OpFunction %void None %3
%5 = OpLabel
%14 = OpAccessChain %_ptr_Uniform__runtimearr_float %_ %int_0
%15 = OpLoad %_runtimearr_float %14
%16 = OpAccessChain %_ptr_Uniform__runtimearr_float %_ %int_0
OpStore %16 %15
OpReturn
OpFunctionEnd
```

---

To be honest, this is mostly an academic issue, I was doing research for the [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) project and stumbled across this miscompilation, I didn't run into this in the "real world". However, I believe that compilers should always either output valid code, or produce an error, so I'm reporting this bug~

Thanks for your time!

Contributor guide

Open the contributing guide

Research direction

Start by compiling the provided GLSL reproducer with glslangValidator -V and inspect the generated OpLoad instruction against the SPIR-V specification. The issue is done when the compiler either emits valid SPIR-V for this assignment or reports an error instead of producing an illegal runtime-array load.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.