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

[Tapani Pälli]

On 06/06/2014 09:14 PM, Matt Turner wrote:
> 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)

OK, now I found the relevant text also. In implicit conversions section
there is also: "There are no implicit conversions between signed and
unsigned integers.".

> 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.

Implicit conversion rules state that "an integer value may appear where
a floating-point type is expected" but I did not see any mention
(reading 1.50.09 spec) that this is allowed other way around. Which spec
version is this?

// Tapani