[Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=109532

--- Comment #18 from Ian Romanick <idr at freedesktop.org> ---
(In reply to asimiklit from comment #7)
> (In reply to Ilia Mirkin from comment #2)
> > Looks like this is happening in link_uniform_blocks. The type gets updated:
> > 
> >       if (b->array != NULL &&
> >           (b->type->without_array()->interface_packing ==
> >            GLSL_INTERFACE_PACKING_PACKED)) {
> >          b->type = resize_block_array(b->type, b->array);
> >          b->var->type = b->type;
> >       }
> > 
> > But no change to the corresponding max_data_access. However doing the naive
> > thing here didn't help -- the shader fails. I didn't investigate why. I
> > think create_buffer_blocks also needs to be involved somehow.
> 
> Thanks a lot your message was very helpful to find the start point of
> investigation.
> 
> Looks like this thing is helped:
> 
> ---
>  src/compiler/glsl/link_uniform_blocks.cpp | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/compiler/glsl/link_uniform_blocks.cpp
> b/src/compiler/glsl/link_uniform_blocks.cpp
> index 0b890586298..5197870a6d9 100644
> --- a/src/compiler/glsl/link_uniform_blocks.cpp
> +++ b/src/compiler/glsl/link_uniform_blocks.cpp
> @@ -438,8 +438,15 @@ link_uniform_blocks(void *mem_ctx,
>        if (b->array != NULL &&
>            (b->type->without_array()->interface_packing ==
>             GLSL_INTERFACE_PACKING_PACKED)) {
> +         const int new_max_array_access =
> (int)(b->array->num_array_elements - 1);
>           b->type = resize_block_array(b->type, b->array);
>           b->var->type = b->type;
> +
> +         assert(((int)b->array->array_elements[new_max_array_access] ==
> +                b->var->data.max_array_access ||
> +                b->var->data.max_array_access == -1) && "Is last index is
> proper");
> +
> +         b->var->data.max_array_access = new_max_array_access;
>        }
>  
>        block_size.num_active_uniforms = 0;

I don't think this has any chance of being correct.  max_array_access is set
based on actual, known accesses to the array.  Changing that arbitrarily is
just lying to the rest of the compiler.  Nothing good can come from that. 
Since the type of the array is now wrong, my guess is that the test fails
(instead of crashes) because the part of the array that has the data the shader
wants is optimized away.

How does the mismatch between max_array_access and the type occur in the first
place?  My guess is that this is the source of the bug.  They *must* agree at
some point, or an earlier part of the compile would have generated an error (as
required by the spec).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190208/71e486f9/attachment.html>