Probably, the optimizer sees that there is second assignment, and skips the
first, f=1.0. It never gets to second though.
On Wed, Apr 10, 2013 at 11:08 PM, Ian Romanick <i...@freedesktop.org> wrote:
> On 04/10/2013 12:20 PM, Vadim Girlin wrote:
>
>> Hi,
>>
>> It seems there is a bug in the compiler. The problem may be reproduced
>> with the following shader (complete shader_test file attached):
>>
>> void main()
>> {
>> float f = 0.0;
>> while (true) {
>> f = 1.0;
>> break;
>> f = 0.5;
>> }
>> gl_FragColor = vec4(1.0 - f, f, 0.0, 1.0);
>> }
>>
>> The result of compilation is equal to:
>>
>> while (true) {
>> break;
>> }
>> gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
>>
>> In other words, GLSL compiler eliminates both assignments to "f" in the
>> loop body and the resulting value of the "f" variable is 0.
>>
>
> Blarg. I can believe it. The loop analysis code is a disaster. Part of
> the reason I'm (slowly) making changes to the IR is so that we can do more
> credible loop handling.
>
> I probably won't be able to get to this problem for quite some time. :(
>
> Vadim
>> ______________________________**_________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev>
>>
>
> ______________________________**_________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
