[Piglit] [PATCH] glsl-1.30: test unsigned vs signed in switch statement

[Matt Turner]

On Fri, Jun 6, 2014 at 5:26 AM, Tapani Pälli <tapani.palli at intel.com> wrote:
> Signed-off-by: Tapani Pälli <tapani.palli at intel.com>
> ---
>  .../switch-statement/switch-uint-vs-int.vert        | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>  create mode 100644 tests/spec/glsl-1.30/compiler/switch-statement/switch-uint-vs-int.vert
>
> diff --git a/tests/spec/glsl-1.30/compiler/switch-statement/switch-uint-vs-int.vert b/tests/spec/glsl-1.30/compiler/switch-statement/switch-uint-vs-int.vert
> new file mode 100644
> index 0000000..d749318
> --- /dev/null
> +++ b/tests/spec/glsl-1.30/compiler/switch-statement/switch-uint-vs-int.vert
> @@ -0,0 +1,21 @@
> +// [config]
> +// expect_result: fail
> +// glsl_version: 1.30
> +// [end config]
> +//
> +// Test checks that compiler issues a warning on
> +// using unsigned vs signed type in a switch.

Nothing about a warning. The compiler should reject this, since by
inference the code is doing 1u == 1, which is isn't allowed (at least
until ARB_gpu_shader5 adds more implicit conversion rules? We'll
probably want a test like this for those rules)

Let's add a spec citation for ==

The equality operators equal (==), and not equal (!=) operate on all
types. They result in a scalar
Boolean. If the operand types do not match, then there must be a
conversion from Section 4.1.10
“Implicit Conversions” applied to one operand that can make them
match, in which case this
conversion is done.

and for switch

The type of init-expression in a switch statement must be a scalar integer.

I'm using a 150 spec, but you'll want to find them in the 130 spec.

> +//
> +
> +#version 130
> +
> +void main() {
> +   uint x = 1u;
> +   switch (x) {
> +   case 1:
> +   break;

Indent the breaks.

> +   default:
> +   break;
> +   }
> +   gl_Position = vec4(0.0);
> +}
> --
> 1.8.3.1

Otherwise, looks good.

Another interesting case is

int x = 1;
switch (x)
case 1.0:
}

The init-expression is a scalar integer, and implicit conversion rules
would allow 1 == 1.0. It looks like there's a Khronos conformance
suite test that confirms that this fails. That wouldn't have been so
clear to me.