Are you sure that's correct? It's unclear from the spec that you should be able to set arbitrary array indices' frag data locations/index values. Your test case works with:

diff --git a/blend_func_extended_array/Main.cpp b/blend_func_extended_array/Main.cpp
index 5718d0f..31217ee 100644
--- a/blend_func_extended_array/Main.cpp
+++ b/blend_func_extended_array/Main.cpp
@@ -29,8 +29,8 @@ class BlendFuncExtendedArray : public GLFWApp {
                    })";
 
             mProgram = CompileProgramStuffBeforeLink(vs, fs, [](GLuint program){
-                glBindFragDataLocationIndexed(program, 0, 0, "FragData[0]");
-                glBindFragDataLocationIndexed(program, 0, 1, "SecondaryFragData[0]");
+                glBindFragDataLocationIndexed(program, 0, 0, "FragData");
+                glBindFragDataLocationIndexed(program, 0, 1, "SecondaryFragData");
             });
             std::cout << "Location of FragData, should be 0: " << glGetFragDataLocation(mProgram, "FragData[0]") << std::endl;
             std::cout << "Index of FragData, should be 0: " << glGetFragDataIndex(mProgram, "FragData[0]") << std::endl;


Note that it's still arrays in the glsl.

Does this work with other drivers? If so, which ones?

Thanks for taking a look, indeed my understanding was wrong but I found a Khronos bug related to this that doesn't have a formal resolution but indicates that while you can't bind array elements individually, "array[0]" should be equivalent to "array". See https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7829

Unfortunately Chrome has been testing this on few platforms, so far it only tested NVIDIA proprietary (passes), fglrx (doesn't pass). It also fails on the OSX drivers, seemingly for the same reason as for Mesa it seems.

Given all the above, I will fix Chromium's tests to not use indices, can you still consider making the [0] equivalent to no subscript?

Thank you for your time.

(In reply to Corentin Wallez from comment #2)
> Thanks for taking a look, indeed my understanding was wrong but I found a
> Khronos bug related to this that doesn't have a formal resolution but
> indicates that while you can't bind array elements individually, "array[0]"
> should be equivalent to "array". See
> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7829
> 
> Unfortunately Chrome has been testing this on few platforms, so far it only
> tested NVIDIA proprietary (passes), fglrx (doesn't pass). It also fails on
> the OSX drivers, seemingly for the same reason as for Mesa it seems.
> 
> Given all the above, I will fix Chromium's tests to not use indices, can you
> still consider making the [0] equivalent to no subscript?
> 
> Thank you for your time.

That does seem reasonable. As I'm not one of the cool kids with KHR access, mind letting me know what that bug says about what to do when someone binds both "array" and "array[0]"? Right now we store these in a map, and resolve locations at link time (as per the spec). We don't know what's an array and what's not at bind time.

Also, does the bug make any comments about AoA? i.e.

out vec4 foo[2][2][2]

Should you be able to bind with "foo[0][0][0]"? What about "foo[0][0]" and "foo[0]" in that case? [Perhaps the AoA spec says something about this, I'm not up on all the details myself.]

The bug indicates that "array" and "array[0]" are identical so I'd assume that the binding done last takes precedence. I'm not sure about AofA, or if it's even allowed for fragment outputs.

Here's the relevant bit from the bug where a parallel with ARB_program_interface_query is made:

> I think my recommendation would be to adopt language similar to that for GetProgramResourceIndex(), allowing you to drop the "[0]" but not to address individual elements.  I don't think we want you to be able to assign "array[0]" to location 3 and "array[1]" to location 5, for example.

I also tried the changes you mentioned in Comment 1, while it fixes the values queried back from the driver, the triangle is still not being shown. Only making FragColor and SecondaryFragColor to be non-array floats make the triangle appear.

(In reply to Corentin Wallez from comment #4)
> I also tried the changes you mentioned in Comment 1, while it fixes the
> values queried back from the driver, the triangle is still not being shown.
> Only making FragColor and SecondaryFragColor to be non-array floats make the
> triangle appear.

Ah, right you are. I'm used to seeing piglit print a failure message when it didn't work. More investigating is left here.

Oh, actually it should work now with the patch I pushed out last night but failed to mention, since it wasn't addressing the array issue. Double-checked on i965:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=a37e46323c7e18bec4160f2f66847c10b7041dc1

commit a37e46323c7e18bec4160f2f66847c10b7041dc1
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Fri Jul 1 19:10:36 2016 -0400

    glsl: don't try to lower non-gl builtins as if they were gl_FragData
    
    If a shader has an output array, it will get treated as though it were
    gl_FragData and rewritten into gl_out_FragData instances. We only want
    this to happen on the actual gl_FragData and not everything else.
    
    This is a small part of the problem pointed out by the below bug.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96765
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>

[BTW, your repo appears to have obtained a bug where you try to do glGetString(GL_EXTENSIONS) and die when it's not there -- you're supposed to use glGetStringi(GL_EXTENSIONS) in core contexts.]

Thank you, I'm still figuring out how to test top of tree Mesa and will confirm if that fixes all the failures.

I've fixed the core profile GL_EXTENSIONS bug locally, will push to the repo.

https://patchwork.freedesktop.org/patch/97464/

This patch should also fix it for the [0] names. I chose to implement it as a fallback thing, so if you have foo and foo[0] set, foo will always get picked, no matter which was set first.

If I stripped the [0]'s at bind time, one might run into the issue of a

out vec4 foo;

shader (which, as the spec says, can be added after the binding is done on the program), and someone doing a bind on both foo and foo[0], and it'd be awkward for the foo[0] to win out in that case.

Mesa 12.0 with your patch applied fixes all the remaining failures in the relevant Chromium tests.

There's still one failure but it is trying to set FragData[0] = 2 and FragData[1] = 1 which is invalid given the discussion in the Khronos bug tracker. I'll fix this on our side.

Thank you again for fixing this!