Found Intel GLSL function-inlining compiler bug

[Benjamin_Rosseaux]

Hello,

I’ve found a bug in the Intel GLSL compiler on my rMBP2015 under Windows, while working on a new Farbrausch 64k intro for the UnderConstruction 2016 demoparty on the 27th-29th 2016, so the following wrong-running code:

float opSub(const in float d1, const in float d2){
 return max(d1, -d2);
}
....
d = opSub(d, opSub(length(lp.xz) — 2.2, p.y — 6.0));
d = opSub(d, opSub(length(lp.xz — vec2(0.0, -1.6)) — 0.7, p.y — 6.0));

has a different (and wrong) behavior (where opSub will be get a mixed behaviour of opUnion and opIntersection) than this then-right-running code:

#define opSub(d1,d2) max((d1), -(d2)) 
....
d = opSub(d, opSub(length(lp.xz) — 2.2, p.y — 6.0));
d = opSub(d, opSub(length(lp.xz — vec2(0.0, -1.6)) — 0.7, p.y — 6.0));

and also then-right-running code variant:

float opSub(const in float d1, const in float d2){
 return max(d1, -d2);
}
....
float temp = opSub(length(lp.xz) — 2.2, p.y — 6.0);
d = opSub(d, temp);
temp = opSub(length(lp.xz — vec2(0.0, -1.6)) — 0.7, p.y — 6.0)
d = opSub(d, temp);

So, there seems to be also a bug in the auto-inlining-function-feature and/or register-allocation of the Intel GLSL compiler, I guess.

For see this one issue in action, see my testcase with complete GLSL code at see https://www.youtube.com/watch?v=u0dNKo70X8s and https://gist.github.com/BeRo1985/3a47c5be8b08381edb2d670a13bca606 or here as post file attachment

Regards from Germany,
Benjamin Rosseaux