[BUG] GLSL compiler seems to set a wrong position of the buffer


According to me, the following code changes the third value of the buffer. However, it changes the first value when using the nvidia 460.80 driver under ubuntu 21.1.

Initialization values of the buffer are given by the comments.

#version 310 es
layout(local_size_x = 1, local_size_y = 1, local_size_z = 1) in;
layout(std430, binding = 0) buffer buffer_0 {
 int ext_2[3]; // 2 0 -2
 int ext_3[1]; // -2147483648
} ;

int return_zero() //return 0
 return 0;
void set_1(inout int A, int B) //set 1
 return A = 1;
void main()
    set_1(ext_2[clamp(~ext_3[0], 0, 2)], ext_3[return_zero()] += -2147483648);

Nvidia output:

buffer_0 1 0 -2 0

Expected output:

buffer_0 2 0 1 0

Thinking process:

  • set_1 the value on the left argument (a position in ext_2) to 1, the second parameter is unused.
  • the position is given by clamp(~ext_3[0],0,2) where ext_3[0] = -2147483648
  • ~ext_3[0] = 2147483647 so that clamp(~ext_3[0],0,2)=2

From what I understand from the OpenGL ES 3.1 specification (6.1.1 Function Calling Conventions), parameters should be evaluated from left to right, so that the side effect on the second parameter should have no effect to the position in the first parameter.

Code links

For the related code in the shadertrap test format, see: nvidia/miscompilation/shader02.shadertrap or shader02.shadertrap (812 Bytes).
Compute shader only:
shader02.comp (396 Bytes)

I can confirm in the shadertrap
and even in fragment Shader (only in OpenGL)
Fragment shader version Shader - Shadertoy BETA
(Linux Nvidia, but it does not matter it same)

This bug happens only in OpenGL, but it does not mean that Nvidia Vulkan is fine, look my bugreports where I trigger same array compiler(I think) bugs from Vulkan:

Similar my OpenGL bug: