I found inconsistent and unexpected behavior when accessing components of a dvec4 within a loop using a non-constant loop condition. Broken down to a working minimal compute shader example:
#version 450
#extension GL_NV_gpu_shader5 : enable
#extension GL_NV_shader_buffer_load : enable
layout(local_size_x = 32, local_size_y = 1, local_size_z = 1) in;
uniform restrict double* results;
uniform bool useThreeComponents;
void main()
{
int numComponents = (useThreeComponents) ? 3 : 4;
dvec4 weights;
for (int j = 0; j < numComponents; j++)
{
weights[j] = double(j);
}
results[0] = weights[0]; // Just so the calculation is not optimized away
}
The problem in this code is that I access the components of weights with the array operator, which is a no-go when i could possibly be out of bounds. Although I semantically guarantee that the loop will not iterate more than four times, this might not be apparent to the compiler/linker. No problem with that. However, this yields the linker error:
Compute info
------------
(0) : fatal error C9999: can't find __setVectorIndex function in stdlib
This error is really nondescript for the shader programmer and only adds to one’s frustration. At the very least, this error should be improved. For example, when replacing numComponents with the constant 5, I get the error:
Compute info
------------
0(16) : error C1068: array index out of bounds
0(16) : error C1011: cannot index a non-array value
I’d love to see something similar for my case above.
The second part of this bug is that it only occurs with dvec2, dvec3 and dvec3, but not with vec* or ivec*. When I use vec4 and actually go out of bounds, the context silently dies and I get an access violation the next time I try to do something with the GL. No matter what behavior is implemented in the end, it should at least be consistent among the different data types.
Tested on a Win 8.1 64 bit system with 368.81 drivers.