i965/gs: Properly skip GS binding table upload when no GS active.

Previously, in brw_gs_upload_binding_table(), we checked whether
brw->gs.prog_data was NULL in order to determine whether a geometry
shader was active.  This didn't work: brw->gs.prog_data starts off as
NULL, but it is set to non-NULL when a geometry shader program is
built, and then never set to NULL again.  As a result, if we called
brw_gs_upload_binding_table() while there was no geometry shader
active, but a geometry shader had previously been active, it would
refer to a stale (and possibly freed) prog_data structure.

This patch fixes the problem by modifying
brw_gs_upload_binding_table() to use the proper technique to determine
whether a geometry shader is active: by checking whether
brw->geometry_program is NULL.

I suspect this may address the crash reported in comment 2 of bug
71870.

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

Cc: mesa-stable@lists.freedesktop.org
i965/gs: Set GS prog_data to NULL if there is no GS program.

The previous commit fixes a bug wherein we would incorrectly refer to
stale geometry shader prog_data when no geometry shader was active.

This patch reduces the likelihood of that sort of bug occurring in the
future by setting prog_data to NULL whenever there is no GS program.

Cc: mesa-stable@lists.freedesktop.org
glsl: Fix lowering of direct assignment in lower_clip_distance.

In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an
ir_rvalue_visitor), we failed to notice that since
lower_clip_distance_visitor overrides visit_leave(ir_assignment *),
ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called.
As a result, clip distance dereferences appearing directly on the
right hand side of an assignment (not in a subexpression) weren't
getting properly lowered.  This caused an ir_dereference_variable node
to be left in the IR that referred to the old gl_ClipDistance
variable.  However, since the lowering pass replaces gl_ClipDistance
with gl_ClipDistanceMESA, this turned into a dangling pointer when the
IR got reparented.

Prior to the introduction of geometry shaders, this bug was unlikely
to arise, because (a) reading from gl_ClipDistance[i] in the fragment
shader was rare, and (b) when it happened, it was likely that it would
either appear in a subexpression, or be hoisted into a subexpression
by tree grafting.

However, in a geometry shader, we're likely to see a statement like
this, which would trigger the bug:

    gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i];

This patch causes
lower_clip_distance_visitor::visit_leave(ir_assignment *) to call the
base class visitor, so that the right hand side of the assignment is
properly lowered.

Fixes piglit test:
- spec/glsl-1.50/execution/geometry/clip-distance-itemized-copy

Cc: Ian Romanick <idr@freedesktop.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
glsl/linker: Validate IR just before reparenting.

If reparent_ir() is called on invalid IR, then there's a danger that
it will fail to reparent all of the necessary nodes.  For example, if
the IR contains an ir_dereference_variable which refers to an
ir_variable that's not in the tree, that ir_variable won't get
reparented, resulting in subtle use-after-free bugs once the
non-reparented nodes are freed.  (This is exactly what happened in the
bug fixed by the previous commit).

This patch makes this kind of bug far easier to track down, by
transforming it from a use-after-free bug into an explicit IR
validation error.
!UPSTREAM: i965/gs: Generalize some error messages for GS.

TODO: find more places to generalize.
TODO: Don't use "VS/GS" terminology.  Use "vec4" terminology, since that will endure longer.
!UPSTREAM: glsl/linker: Fail if linking geometry shader with 0 GEOMETRY_VERTICES_OUT.

ARB_geometry_shader4 spec 2.15.2:
"Linking will also fail [...] if the program object contains objects to form a
geometry shader, and the value of GEOMETRY_VERTICES_OUT_ARB is zero."

Reviewed-by: Paul Berry <stereotype441@gmail.com>

TODO: May not be necessary for GLSL 1.50 style geometry shaders.  Make a test to validate.
!UPSTREAM: Work around bug in AntTweakBar

AntTweakBar tries to use glGetString(GL_EXTENSIONS) when connected to
a core context (it should use glGetStringi()).  Go ahead and allow
this for the time being.
!UPSTREAM: main: check texture target when validating layered framebuffers.

From section 4.4.4 (Framebuffer Completeness) of the GL 3.2 spec:

    If any framebuffer attachment is layered, all populated
    attachments must be layered. Additionally, all populated color
    attachments must be from textures of the same target.

We weren't checking that the attachments were from textures of the
same target.

TODO:
- Make a piglit test for this, and validate it on Nvidia.