Bug 66292

It also happens on mesa 9.1 branch.
Bisect shows:c170c901d0f5384e5ab8b79b827663fa28439b0b is the first bad commit.
commit c170c901d0f5384e5ab8b79b827663fa28439b0b
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Fri Jun 7 17:05:22 2013 -0700

    glsl: Move all var decls to the front of the IR list in reverse order

    This has the (intended!) side effect that vertex shader inputs and
    fragment shader outputs will appear in the IR in the same order that
    they appeared in the shader code.  This results in the locations being
    assigned in the declared order.  Many (arguably buggy) applications
    depend on this behavior, and it matches what nearly all other drivers
    do.

    Fixes the (new) piglit test attrib-assignments.

    NOTE: This is a candidate for stable release branches (and requires the
    previous commit to prevent a regression in OpenGL ES 2.0 conformance
    test stencil_plane_operation).

    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

It also happens on sandybridge.

I can reproduce this, I don't quite understand why the test fails though as it uses glGetAttribLocation to fetch locations so it should not depend on particular location. Maybe commit c170c901d0f5384e5ab8b79b827663fa28439b0b should sort only the variables coming from user and ignore language variables like gl_Position or gl_DepthRange. With re-ordering the variables are in same order declared but in the bottom of the ir list. I will investigate more to gain better understanding.

Created attachment 83343 [details]
patch to fix/workaround the issue

Attaching a patch that fixes the issue, when linking it marks locations used by builtin variables to used_locations mask. However, I'm not sure if this is the right cure, Ian please comment.

like I was afraid I think the patch actually just hides the issue as location 0 gets unutilized this way, location 0 seems to be the problem here, 'used_locations |= (1 << 0)' seems enough of a workaround. Will try to figure out why.

Robert's patch in bug #55503 makes these tests work.

I have posted a somewhat different patch to the mesa-dev mailing list for review:

http://lists.freedesktop.org/archives/mesa-dev/2013-August/042881.html

commit 41eef83cc030e7087b79b0070d00fbc56538fb81
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Wed Aug 7 11:15:41 2013 -0700

    mesa/vbo: Fix handling of attribute 0 in non-compatibilty contexts
    
    It is only in OpenGL compatibility-style contexts where generic
    attribute 0 and GL_VERTEX_ARRAY have a bizzare, aliasing relationship.
    Moreover, it is only in OpenGL compatibility-style contexts and OpenGL
    ES 1.x where one of these attributes provokes the vertex.  In all other
    APIs each implicit call to glArrayElement provokes a vertex regardless
    of which attributes are enabled.
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Robert Bragg <robert@sixbynine.org>
    Cc: "9.0 9.1 9.2" <mesa-stable@lists.freedesktop.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55503
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66292
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67548

Verified.Fixed.