Seems the test has some errors.

For instance, it declares a shader with the following definition:

~~~
#version 430 core
#extension GL_ARB_enhanced_layouts : require

out Goku {
    vec4 gohan;
    layout (location = 4) vec4 goten;
    vec4 chichi;
} goku;

in  vec4 in_vs;
out vec4 vs_tcs;
~~~

As seen, "goten" has location qualifier, but not the other members, nor the "Goku" block.

According to GL_ARB_enhanced_layouts:

"It is a compile-time error to declare a block with some of its members 
 having a location, but not all.  Thus, if a block has no 
 block-level *location* layout qualifier, it is required that either all 
 or none of its members have a *location* layout qualifier."

While I didn't see a shader where only some members had locations, my analysis was that it produces shaders whose interfaces have locations on one side but not the other. https://github.com/KhronosGroup/VK-GL-CTS/issues/55

I'm pretty sure this is illegal, but not 100% sure.

Hi, as I understand it, the test tests that when not all members have explicit location, a compilation error is produced. So this block, is to produce the compile error.

There is another issue though and the test fails (linking error) in my case:

Some shader stages use this block:
Goku {
    vec4 gohan;
    vec4 goten;
    vec4 chichi;
} gokuARRAY;

whereas some others use this:
Goku {
    layout (location = 2) vec4 gohan;
    layout (location = 4) vec4 goten;
    layout (location = 6) vec4 chichi;
} gokuARRAY;

The blocks don't match and a linker error is produce. If I force the use of the same block, then the test passes. I am looking at this issue.

Section 4.7.1 from OpenGL 4.5 spec says:

When multiple shader stages are active, the outputs of one stage form an interface
with the inputs of the next stage. At each such interface, shader inputs are matched
up against outputs from the previous stage:
• An output block is  considered to match an input block in  the subsequent
shader if the two blocks have the same block name, and the members of the
block match exactly in name, type, qualification, and declaration order.
•An output variable is considered to match an input variable in the subsequent
shader if:
– the two variables match in name, type, and qualification,   and neither
has a location qualifier, or
– the   two   variables   are   declared   with   the   same
location and component layout qualifiers and match in type and qualification.

-----------------------------------------

As I understand it, this declaration (D1):

out Goku {
    vec4 gohan;
    layout (location = 4) vec4 goten;
    vec4 chichi;
} goku

is the wrong one, and it is put there to produce the compile error. The bug in the test is that the declaration (D2):

Goku {
    vec4 gohan;
    vec4 goten;
    vec4 chichi;
} gokuARRAY;

doesn't match the declaration (D3):

Goku {
    layout (location = 2) vec4 gohan;
    layout (location = 4) vec4 goten;
    layout (location = 6) vec4 chichi;
} gokuARRAY;

because they have different qualification and that causes an unexpected linker error. I am going to fix the test to use either D1-D2 or D1-D3 block declarations, because I think that the combination of D1, D2, D3 is responsible for the failure.

Hi Eleni,

Ilia also found this bug:
https://github.com/KhronosGroup/VK-GL-CTS/issues/55

I think you're right, we just need to fix the test.

If you're looking at more enhanced layouts failures, Ilia has some other bugs open here:

https://github.com/KhronosGroup/VK-GL-CTS/issues?q=is%3Aissue+is%3Aopen+label%3AOpenGL

(In reply to Kenneth Graunke from comment #5)
> Hi Eleni,
> 
> Ilia also found this bug:
> https://github.com/KhronosGroup/VK-GL-CTS/issues/55
> 
> I think you're right, we just need to fix the test.

Thanks, I've replied to this bug too and I proposed a fix for the issue.

> 
> If you're looking at more enhanced layouts failures, Ilia has some other
> bugs open here:
> 
> https://github.com/KhronosGroup/VK-GL-CTS/
> issues?q=is%3Aissue+is%3Aopen+label%3AOpenGL

Thanks, I will get a look!

Eleni's fix is here: https://gerrit.khronos.org/1661

Hopefully that will land soon, at which point we can close this as NOTOURBUG.

I think this was fixed by the following VK-GL-CTS commit:

commit 9aba5ace6950c0f642a3cd121c64959e1a4a738f
Author: Eleni Maria Stea <estea@igalia.com>
Date:   Wed Sep 20 14:28:40 2017 +0300

    Fix KHR-GL45/46.enhanced_layouts.varying_block_member_locations