<div dir="ltr">On 27 September 2013 14:04, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/27/2013 01:37 PM, Paul Berry wrote:<br>
> These tests verify that unsized arrays appearing inside interface<br>
> blocks are subject to the same restrictions as unsized arrays<br>
> appearing outside interface blocks (e.g. they can't be used in bulk<br>
> assignment, they don't support .length(), and they can't be accessed<br>
> using a non-constant index).<br>
><br>
> Since it's likely that these restrictions are enforced by the same<br>
> code as for unsized arrays appearing outside of interface blocks,<br>
> these are just a few touch tests; we don't exhaustively test all<br>
> possible types of access in every shader type.<br>
<br>
</div>The last two tests look great as-is.  The first one needs a minor<br>
change, I think.  With that,<br>
<br>
Reviewed-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>><br>
<div><div class="h5"><br>
> ---<br>
>  ...ment-to-unsized-array-in-unnamed-ifc-block.vert | 27 ++++++++++++++++++++++<br>
>  ...length-of-unsized-array-in-array-ifc-block.geom | 27 ++++++++++++++++++++++<br>
>  ...access-to-unsized-array-in-named-ifc-block.frag | 23 ++++++++++++++++++<br>
>  3 files changed, 77 insertions(+)<br>
>  create mode 100644 tests/spec/glsl-1.50/compiler/illegal-assignment-to-unsized-array-in-unnamed-ifc-block.vert<br>
>  create mode 100644 tests/spec/glsl-1.50/compiler/illegal-length-of-unsized-array-in-array-ifc-block.geom<br>
>  create mode 100644 tests/spec/glsl-1.50/compiler/illegal-nonconst-access-to-unsized-array-in-named-ifc-block.frag<br>
><br>
> diff --git a/tests/spec/glsl-1.50/compiler/illegal-assignment-to-unsized-array-in-unnamed-ifc-block.vert b/tests/spec/glsl-1.50/compiler/illegal-assignment-to-unsized-array-in-unnamed-ifc-block.vert<br>
> new file mode 100644<br>
> index 0000000..7df2868<br>
> --- /dev/null<br>
> +++ b/tests/spec/glsl-1.50/compiler/illegal-assignment-to-unsized-array-in-unnamed-ifc-block.vert<br>
> @@ -0,0 +1,27 @@<br>
> +// [config]<br>
> +// expect_result: fail<br>
> +// glsl_version: 1.50<br>
> +// check_link: true<br>
> +// [end config]<br>
> +//<br>
> +// Test that if an interface block contains an unsized array, it is<br>
> +// illegal to use it as the LHS of a bulk assignment (even if both the<br>
> +// LHS and the RHS of the assignment have the same implied array<br>
> +// size).<br>
> +//<br>
> +// This test uses an unnamed interface block.<br>
> +<br>
> +#version 150<br>
> +<br>
> +out block {<br>
> +  float foo[];<br>
> +};<br>
> +<br>
> +void main()<br>
> +{<br>
> +  float bar[];<br>
> +  bar[0] = 1.0;<br>
> +  bar[1] = 2.0;<br>
> +  foo = bar;<br>
> +  foo[1] = 3.0;<br>
> +}<br>
<br>
</div></div>This should fail regardless due to bar.  Maybe put a size on bar so that<br>
only foo is unsized?<br></blockquote><div><br></div><div>Yeah, that seems reasonable.  Thanks.<br></div></div></div></div>