KhronosGroup / KhronosGroup/glslang
Invalid SPIR-V can be generated: OpLoad a pointer to a OpTypeRuntimeArray
- 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
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