[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon at freedesktop.org]

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

--- Comment #16 from iive at yahoo.com ---
(In reply to Ilia Mirkin from comment #11)
> As an aside... there's no compilation bug here. Perhaps $other driver
> happens to get you a value of 0, but nothing guarantees that. Could just be
> luck in precisely how they do RA. Certainly nothing in the spec.
> 
> And there are legitimate situations where a variable might be uninitialized
> prior to (compiler-proven) use, e.g.
> 
> int x;
> int y = 0;
> loop {
>   if (a)
>     y += x;
>   if (b)
>     x = 5;
> }
> 
> The compiler couldn't reasonably prove that a never happens before b does
> (except in some circumstances).
> 
> Would it be the end of the world if one were to add code to zero-initialize
> all variables? No - but it'd add unnecessary code to otherwise functioning
> shaders.
> 
> Mesa tends to stick to what's required by the spec.


The spec might not define what you should do in this case, but this means that
we are free to handle the case as we see fit. Especially if we do something
reasonable and consistent.

If the compiler cannot reasonably prove that the variable will be initialized
and the loop will finish, then maybe that is because it wont.

It is possible that the shader would work properly only for a limited range of
inputs. If these inputs are result of previous rendering, it might cause an
extremely hard to trigger and reproduce bugs/hangs.

With SSA and phi it is very easy to find when variable is used uninitialized
and handle the case in deterministic way.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180328/008a1d37/attachment.html>