arb_fragment_shader_interlock: Additional compile tests

The negative tests in this group require some inference from various
specs.  A spec bug has been submitted against the
GL_ARB_fragment_shader_interlock spec.

Currently none of the negative tests produce the expected result on
Mesa.

v2: Add test for switch-statements.  Noticed by Jason.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

16 files changed, 761 insertions, 0 deletions

diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag
new file mode 100644
index 000000000..1c74fa49c
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag
@@ -0,0 +1,27 @@
+// [config]
+// expect_result: pass
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+in float f;
+
+void main()
+{
+	if (f < 0.5)
+		discard;
+
+	beginInvocationInterlockARB();
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag
new file mode 100644
index 000000000..29493ff9e
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag
@@ -0,0 +1,51 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+uniform bool condition;
+
+void main()
+{
+	if (condition)
+		return;
+
+	beginInvocationInterlockARB();
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag
new file mode 100644
index 000000000..f68d7936a
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag
@@ -0,0 +1,49 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	do {
+		beginInvocationInterlockARB();
+	} while (false);
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag
new file mode 100644
index 000000000..2ca54bc8a
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag
@@ -0,0 +1,50 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	for (;;) {
+		beginInvocationInterlockARB();
+		break;
+	}
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag
new file mode 100644
index 000000000..53fe7e7d9
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag
@@ -0,0 +1,48 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	if (true)
+		beginInvocationInterlockARB();
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag
new file mode 100644
index 000000000..63c1c6c4b
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag
@@ -0,0 +1,51 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void wrapper()
+{
+	beginInvocationInterlockARB();
+}
+
+void main()
+{
+	wrapper();
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-switch.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-switch.frag
new file mode 100644
index 000000000..2b982b1f4
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-switch.frag
@@ -0,0 +1,54 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+uniform int c;
+
+void main()
+{
+	switch (c) {
+	case 0:
+	default:
+		beginInvocationInterlockARB();
+		break;
+	}
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag
new file mode 100644
index 000000000..6283c5ef7
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag
@@ -0,0 +1,49 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    A compile- or link-time error will be generated if main() calls either
+ *    function more than once, contains a call to one function without a
+ *    matching call to the other, or calls endInvocationInterlockARB() before
+ *    calling beginInvocationInterlockARB().
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB() functions
+ *        delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	while (true) {
+		beginInvocationInterlockARB();
+		break;
+	}
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag
new file mode 100644
index 000000000..82344231d
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag
@@ -0,0 +1,28 @@
+// [config]
+// expect_result: pass
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+in float f;
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	if (f < 0.5)
+		discard;
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag
new file mode 100644
index 000000000..83fcaf47a
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag
@@ -0,0 +1,52 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+uniform bool condition;
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	if (condition)
+		return;
+
+	endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag
new file mode 100644
index 000000000..8875e1ff7
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag
@@ -0,0 +1,49 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	do {
+		endInvocationInterlockARB();
+	} while (false);
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag
new file mode 100644
index 000000000..468054fbf
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag
@@ -0,0 +1,50 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	for (;;) {
+		endInvocationInterlockARB();
+		break;
+	}
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag
new file mode 100644
index 000000000..648f10709
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag
@@ -0,0 +1,48 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	if (true)
+		endInvocationInterlockARB();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag
new file mode 100644
index 000000000..0d34cb765
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag
@@ -0,0 +1,51 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void wrapper()
+{
+	endInvocationInterlockARB();
+}
+
+void main()
+{
+	beginInvocationInterlockARB();
+	wrapper();
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-switch.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-switch.frag
new file mode 100644
index 000000000..5c63967cd
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-switch.frag
@@ -0,0 +1,54 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+uniform int c;
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	switch (c) {
+	case 0:
+	default:
+		endInvocationInterlockARB();
+		break;
+	}
+}
diff --git a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag
new file mode 100644
index 000000000..9b3fc424d
--- /dev/null
+++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag
@@ -0,0 +1,50 @@
+// [config]
+// expect_result: fail
+// glsl_version: 4.20
+// require_extensions: GL_ARB_fragment_shader_interlock
+// check_link: false
+// [end config]
+
+/* The GL_ARB_fragment_shader_interlock spec says:
+ *
+ *    The beginInvocationInterlockARB() and endInvocationInterlockARB() may
+ *    only be placed inside the function main() of a fragment shader and may
+ *    not be called within any flow control.  These functions may not be
+ *    called after a return statement in the function main(), but may be
+ *    called after a discard statement.
+ *
+ * and
+ *
+ *    (8) What restrictions should be imposed on the use of the
+ *        beginInvocationInterlockARB() and endInvocationInterlockARB()
+ *        functions delimiting a critical section?
+ *
+ *      RESOLVED:  We impose restrictions similar to those on the barrier()
+ *      built-in function in tessellation control shaders to ensure that any
+ *      shader using this functionality has a single critical section that can
+ *      be easily identified during compilation...
+ *
+ * The GLSL 4.60 spec says:
+ *
+ *    For tessellation control shaders, the barrier() function may only be
+ *    placed inside the function main() of the tessellation control shader and
+ *    may not be called within any control flow. Barriers are also disallowed
+ *    after a return statement in the function main(). Any such misplaced
+ *    barriers result in a compile-time error.
+ *
+ * From this we infer that the first errors mentioned in the
+ * GL_ARB_fragment_shader_interlock spec are intended to generate compile-time
+ * errors.
+ */
+#version 420
+#extension GL_ARB_fragment_shader_interlock: require
+
+void main()
+{
+	beginInvocationInterlockARB();
+
+	while (true) {
+		endInvocationInterlockARB();
+		break;
+	}
+}