glsl-1.10: add a 'initialization-incompatible-type-propagation' test

Submitted by Danylo Piliaiev on Aug. 15, 2018, 2:23 p.m.

Details

Message ID 20180815142325.15710-1-danylo.piliaiev@globallogic.com
State New
Headers show
Series "glsl-1.10: add a 'initialization-incompatible-type-propagation' test" ( rev: 1 ) in Piglit

Not browsing as part of any series.

Commit Message

Danylo Piliaiev Aug. 15, 2018, 2:23 p.m.
This tests the case when initialising with incompatible type
changed a type of the variable being initialized.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547

Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
---
I'm not sure if it's a proper way to test this. The compilation is intended to
fail but the difference is in the error messages. The correct message is an 
error in initialization line and no errors in accessing to the variables, 
incorrect - additional errors where variables are accessed.
At the moment it tests only that compiler wouldn't crash which happened
in the mentioned bug and fix proposed in
https://patchwork.freedesktop.org/series/48256/

 ...ization-incompatible-type-propagation.frag | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag

Patch hide | download patch | download mbox

diff --git a/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
new file mode 100644
index 000000000..0a1873489
--- /dev/null
+++ b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
@@ -0,0 +1,27 @@ 
+// [config]
+// expect_result: fail
+// glsl_version: 1.10
+// [end config]
+//
+// Initializing a variable using the variable with a wrong type
+// should not affect the type of the variable being initialized.
+// At least it should not crash, see bug:
+// https://bugs.freedesktop.org/show_bug.cgi?id=107547
+//
+// From section 5.8 of the GLSL 1.10 spec:
+//     The assignment operator stores the value of expression into lvalue.
+//     It will compile only if expression and lvalue have the same type.
+
+#version 110
+
+uniform struct {
+        float field;
+} data;
+
+int f() {
+    vec4 a = vec2(0.0);
+    a.w -= 1.0;
+
+    vec2 b = data;
+    b.x -= 1.0;
+}

Comments

On 16/8/18 12:23 am, Danylo Piliaiev wrote:
> This tests the case when initialising with incompatible type
> changed a type of the variable being initialized.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
> 
> Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
> ---
> I'm not sure if it's a proper way to test this. The compilation is intended to
> fail but the difference is in the error messages. The correct message is an
> error in initialization line and no errors in accessing to the variables,
> incorrect - additional errors where variables are accessed.
> At the moment it tests only that compiler wouldn't crash which happened
> in the mentioned bug and fix proposed in
> https://patchwork.freedesktop.org/series/48256/
> 
>   ...ization-incompatible-type-propagation.frag | 27 +++++++++++++++++++
>   1 file changed, 27 insertions(+)
>   create mode 100644 tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
> 
> diff --git a/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
> new file mode 100644
> index 000000000..0a1873489
> --- /dev/null
> +++ b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
> @@ -0,0 +1,27 @@
> +// [config]
> +// expect_result: fail
> +// glsl_version: 1.10
> +// [end config]
> +//
> +// Initializing a variable using the variable with a wrong type
> +// should not affect the type of the variable being initialized.
> +// At least it should not crash, see bug:
> +// https://bugs.freedesktop.org/show_bug.cgi?id=107547
> +//
> +// From section 5.8 of the GLSL 1.10 spec:
> +//     The assignment operator stores the value of expression into lvalue.
> +//     It will compile only if expression and lvalue have the same type.
> +
> +#version 110
> +
> +uniform struct {
> +        float field;
> +} data;
> +
> +int f() {
> +    vec4 a = vec2(0.0);
> +    a.w -= 1.0; > +
> +    vec2 b = data;
> +    b.x -= 1.0;

This looks like it should be split into two different tests. Is there 
any reason you included both tests together?

> +}
>
On 9/17/18 12:28 PM, Timothy Arceri wrote:
> On 16/8/18 12:23 am, Danylo Piliaiev wrote:
>> This tests the case when initialising with incompatible type
>> changed a type of the variable being initialized.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
>>
>> Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
>> ---
>> I'm not sure if it's a proper way to test this. The compilation is 
>> intended to
>> fail but the difference is in the error messages. The correct message 
>> is an
>> error in initialization line and no errors in accessing to the 
>> variables,
>> incorrect - additional errors where variables are accessed.
>> At the moment it tests only that compiler wouldn't crash which happened
>> in the mentioned bug and fix proposed in
>> https://patchwork.freedesktop.org/series/48256/
>>
>>   ...ization-incompatible-type-propagation.frag | 27 +++++++++++++++++++
>>   1 file changed, 27 insertions(+)
>>   create mode 100644 
>> tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
>>
>> diff --git 
>> a/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>> b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>
>> new file mode 100644
>> index 000000000..0a1873489
>> --- /dev/null
>> +++ 
>> b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
>> @@ -0,0 +1,27 @@
>> +// [config]
>> +// expect_result: fail
>> +// glsl_version: 1.10
>> +// [end config]
>> +//
>> +// Initializing a variable using the variable with a wrong type
>> +// should not affect the type of the variable being initialized.
>> +// At least it should not crash, see bug:
>> +// https://bugs.freedesktop.org/show_bug.cgi?id=107547
>> +//
>> +// From section 5.8 of the GLSL 1.10 spec:
>> +//     The assignment operator stores the value of expression into 
>> lvalue.
>> +//     It will compile only if expression and lvalue have the same 
>> type.
>> +
>> +#version 110
>> +
>> +uniform struct {
>> +        float field;
>> +} data;
>> +
>> +int f() {
>> +    vec4 a = vec2(0.0);
>> +    a.w -= 1.0; > +
>> +    vec2 b = data;
>> +    b.x -= 1.0;
>
> This looks like it should be split into two different tests. Is there 
> any reason you included both tests together?
The reason was is that the only thing that is tested here is that Mesa 
doesn't crash when compiling the shader.
Testing whether the assignment of an incompatible type produces an error 
is on the other tests.
I'm not sure at this moment if that was a good reason. I can split it 
into two tests if you find it necessary.
>
>> +}
>>
On 17/9/18 7:56 pm, Danylo Piliaiev wrote:
> On 9/17/18 12:28 PM, Timothy Arceri wrote:
>> On 16/8/18 12:23 am, Danylo Piliaiev wrote:
>>> This tests the case when initialising with incompatible type
>>> changed a type of the variable being initialized.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
>>>
>>> Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
>>> ---
>>> I'm not sure if it's a proper way to test this. The compilation is 
>>> intended to
>>> fail but the difference is in the error messages. The correct message 
>>> is an
>>> error in initialization line and no errors in accessing to the 
>>> variables,
>>> incorrect - additional errors where variables are accessed.
>>> At the moment it tests only that compiler wouldn't crash which happened
>>> in the mentioned bug and fix proposed in
>>> https://patchwork.freedesktop.org/series/48256/
>>>
>>>   ...ization-incompatible-type-propagation.frag | 27 +++++++++++++++++++
>>>   1 file changed, 27 insertions(+)
>>>   create mode 100644 
>>> tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>
>>>
>>> diff --git 
>>> a/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>> b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>
>>> new file mode 100644
>>> index 000000000..0a1873489
>>> --- /dev/null
>>> +++ 
>>> b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>
>>> @@ -0,0 +1,27 @@
>>> +// [config]
>>> +// expect_result: fail
>>> +// glsl_version: 1.10
>>> +// [end config]
>>> +//
>>> +// Initializing a variable using the variable with a wrong type
>>> +// should not affect the type of the variable being initialized.
>>> +// At least it should not crash, see bug:
>>> +// https://bugs.freedesktop.org/show_bug.cgi?id=107547
>>> +//
>>> +// From section 5.8 of the GLSL 1.10 spec:
>>> +//     The assignment operator stores the value of expression into 
>>> lvalue.
>>> +//     It will compile only if expression and lvalue have the same 
>>> type.
>>> +
>>> +#version 110
>>> +
>>> +uniform struct {
>>> +        float field;
>>> +} data;
>>> +
>>> +int f() {
>>> +    vec4 a = vec2(0.0);
>>> +    a.w -= 1.0; > +
>>> +    vec2 b = data;
>>> +    b.x -= 1.0;
>>
>> This looks like it should be split into two different tests. Is there 
>> any reason you included both tests together?
> The reason was is that the only thing that is tested here is that Mesa 
> doesn't crash when compiling the shader.
> Testing whether the assignment of an incompatible type produces an error 
> is on the other tests.
> I'm not sure at this moment if that was a good reason. I can split it 
> into two tests if you find it necessary.

Regardless of what you are testing you still have two tests here. If 
they can both trigger a segfault in different paths they should be spilt 
in two. If they both test the a segfault in the same place then we 
should probably simplify the test.

>>
>>> +}
>>>
>
On 9/17/18 1:01 PM, Timothy Arceri wrote:
> On 17/9/18 7:56 pm, Danylo Piliaiev wrote:
>> On 9/17/18 12:28 PM, Timothy Arceri wrote:
>>> On 16/8/18 12:23 am, Danylo Piliaiev wrote:
>>>> This tests the case when initialising with incompatible type
>>>> changed a type of the variable being initialized.
>>>>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
>>>>
>>>> Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
>>>> ---
>>>> I'm not sure if it's a proper way to test this. The compilation is 
>>>> intended to
>>>> fail but the difference is in the error messages. The correct 
>>>> message is an
>>>> error in initialization line and no errors in accessing to the 
>>>> variables,
>>>> incorrect - additional errors where variables are accessed.
>>>> At the moment it tests only that compiler wouldn't crash which 
>>>> happened
>>>> in the mentioned bug and fix proposed in
>>>> https://patchwork.freedesktop.org/series/48256/
>>>>
>>>>   ...ization-incompatible-type-propagation.frag | 27 
>>>> +++++++++++++++++++
>>>>   1 file changed, 27 insertions(+)
>>>>   create mode 100644 
>>>> tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>>
>>>>
>>>> diff --git 
>>>> a/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>> b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>>
>>>> new file mode 100644
>>>> index 000000000..0a1873489
>>>> --- /dev/null
>>>> +++ 
>>>> b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag 
>>>>
>>>> @@ -0,0 +1,27 @@
>>>> +// [config]
>>>> +// expect_result: fail
>>>> +// glsl_version: 1.10
>>>> +// [end config]
>>>> +//
>>>> +// Initializing a variable using the variable with a wrong type
>>>> +// should not affect the type of the variable being initialized.
>>>> +// At least it should not crash, see bug:
>>>> +// https://bugs.freedesktop.org/show_bug.cgi?id=107547
>>>> +//
>>>> +// From section 5.8 of the GLSL 1.10 spec:
>>>> +//     The assignment operator stores the value of expression into 
>>>> lvalue.
>>>> +//     It will compile only if expression and lvalue have the same 
>>>> type.
>>>> +
>>>> +#version 110
>>>> +
>>>> +uniform struct {
>>>> +        float field;
>>>> +} data;
>>>> +
>>>> +int f() {
>>>> +    vec4 a = vec2(0.0);
>>>> +    a.w -= 1.0; > +
>>>> +    vec2 b = data;
>>>> +    b.x -= 1.0;
>>>
>>> This looks like it should be split into two different tests. Is 
>>> there any reason you included both tests together?
>> The reason was is that the only thing that is tested here is that 
>> Mesa doesn't crash when compiling the shader.
>> Testing whether the assignment of an incompatible type produces an 
>> error is on the other tests.
>> I'm not sure at this moment if that was a good reason. I can split it 
>> into two tests if you find it necessary.
>
> Regardless of what you are testing you still have two tests here. If 
> they can both trigger a segfault in different paths they should be 
> spilt in two. If they both test the a segfault in the same place then 
> we should probably simplify the test.
>
Understood, I'll split it in to two tests. Only one case is causing 
segfault, other one just has a potential.
>>>
>>>> +}
>>>>
>>