@Capehill
Now that I saw it: yes, definitely a Nova bug, no need to look at the source, thanks.

@Capehill
@kas1e
New ogles2 v3.0 wip version is on my FTP. I further improved the unused variable detector (whopping 185 lines now ). As a direct result it now also correctly detects the missing initialization of the int "temp" in this shader. Until now stuff like that could eventually slip through undetected because I didn't correctly handle certain OpDecorations (in this case RelaxedPrecision).

@Daniel
Yeah, works!

But now, when it not "forced" version, then in ShaderJoy we didn't have a warning window about non-init-vars, but only have them when enabled "verbose log" and it just hides in the deep of other output. + shader execution didn't stop. But that all to Capehill, of course :) Check ShaderJoy thread anyway.

@Capehill
@kas1e
Another ogles2 v3 wip update with even more improvements of the uninitialized variables detector is on my FTP. It now correctly detects even more stuff, e.g. in these shaders:

● KissingDonuts, "g" (note: this is the only critical uninitialized variable here, despite what's being said here)
● Glowing Stone, "color"
● Aya Tunnel, "dO" (note: this is the only critical uninitialized variable here, despite what's being said here)
● Glass looking modulo trick, "acc"
● Dancing circles, "f"

A stupid typo prevented the detection of some of those until now. Essentially this typo made the detector look for invalid jump target names in one situation, which in turn led to early quits. The second stupid typo eventually made the detector not start at the true entry point, also leading to early quits sometimes. This one was responsible for the other missed hits.
En passant the performance was increased significantly (although the detector's impact wasn't measurable before already ).

EDIT: didn't check if the followin weren't detected before, those were just coming around in the Mantis right now, so I quickly used those for verification.

● Valentiness, "z" (note: this is the only critical uninitialized variable here, despite what's being said here)
● Intricate circles, "col"
● Another Cloudy Tunnel, "vecOld"
● Solar distortion, "dpMin"

@Daniel
Yeah, detection is better for sure. From all Hans finds find out 2 ones which weren't detected:

http://www.amiga.org/developer/bugreports/view.php?id=592

http://www.amiga.org/developer/bugreports/view.php?id=596


One in MainImage() probabaly is out of detection as you explain before, but another one seems unitialized var in the image() function, so should be detected imho ?

Btw, offten we have in different function declared vars with the same name, and only one or some of them are really unitialized. Question is : is it of much hassle, in the error output with name of unitialized var print a number of string in the shader, or it all up to high level's code ?

@kas1e
Those are the two which I told you on FB cannot be detected "by design". The detector currently doesn't track such (in)outs, they are completely ignored. This won't change in the foreseeable future, most likely.

You mean line numbers? Those are gone in the SPIR-V, usually. However, I could add an aglSetParam-option to enable the emitting of OpLine instructions, which the detector could then pick up easily.
But IMHO that's not worth the bloat. Such shaders usually don't consist out of hundreds of lines. A search for the respective variable name will most often immediately and the rest of the time very quickly lead you to the critical location in the shader anyway.
But if you really want it real hard, then I'll add it
(but note that the line numbers won't necessarily be what you expect in case of ShaderJoy, because the listings get a trailing "invisible" static piece of code attached internally... So if I add support for this, then another optional int agl-parameter for a line-number report-offset would be mandatory, I guess).

@Daniel
No no, not of big deal. Just if it was something very simply like adding another byte to printf, but if not, no need to spend time on. Its good enough already :)

Does those shaders works if those unintialized vars are set manually ?
( I mean edit the shader)

Of course (that what we are talk about). But they tested with 1.74 betas of Nova, so not sure if they all will work after you fix vars with public 1.68.