Reduction producing an inifinite loop about graphicsfuzz HOT 3 OPEN

Thanks for the report! Are you able to provide the working directory for the reduction? This should have loads and loads of JSON files and .frag files - one for each reduction step.

With what you've provided I can see the end result of reduction, but not the log of what happened, and it's that log that would shed light on when the infinite loop arrived.

from graphicsfuzz.

work.tar.gz

This time I hit the same issue with the option that keeps the work dir.

from graphicsfuzz.

Ah, command.log, in the reduction working dir, says:

06:22:55.556 INFO ReductionDriver - The shader is not interesting when global loop limiters are added; these will not be used during reduction, so the final reduced shader could contain long-running or infinite loops.

When moving on to a semantics-changing reduction (reduction 2), glsl-reduce tries to add global loop limiters. If this preserves interestingness of the shader (in your case, it still hits the coverage point) then after every simplification glsl-reduce makes it re-adds global loop limiters, so that the reducer can reduce aggressively and not worry about introducing infinite loops. But if adding global loop limiters in the first place doesn't work (e.g., adding them leads to the bug or coverage point disappearing) then it makes do without them.

This doesn't mean that the bug/coverage point requires an infinite loop, as the original shader probably didn't have an infinite loop. It just means that adding the specific code shape associated with a loop limiter makes the bug/coverage point disappear.

Perhaps we should get gfauto to look for this log message and use it to provide some indication that this happened, before deleting the reduction work dir - what do you think?

from graphicsfuzz.