i965/vec4: Fix hypothetical use of uninitialized data in attribute_map[].

Fixes issue identified by Klocwork analysis:

    'attribute_map' array elements might be used uninitialized in this
    function (vec4_visitor::lower_attributes_to_hw_regs).

The attribute_map array contains the mapping from shader input
attributes to the hardware registers they are stored in.
vec4_vs_visitor::setup_attributes() only populates elements of this
array which, according to core Mesa, are actually used by the shader.
Therefore, when vec4_visitor::lower_attributes_to_hw_regs() accesses
the array to lower a register access in the shader, it should in
principle only access elements of attribute_map that contain valid
data.  However, if a bug ever caused the driver back-end to access an
input that was not flagged as used by core Mesa, then
lower_attributes_to_hw_regs() would access uninitialized memory, which
could cause illegal instructions to get generated, resulting in a
possible GPU hang.

This patch makes the situation more robust by using memset() to
pre-initialize the attribute_map array to zero, so that if such a bug
ever occurred, lower_attributes_to_hw_regs() would generate a (mostly)
harmless access to r0.  In addition, it adds assertions to
lower_attributes_to_hw_regs() so that if we do have such a bug, we're
likely to discover it quickly.
!UPSTREAM ===== BEGIN rebase of Plombo's GS patches =====
draw/gs: fix allocation of buffer for GS output vertices

Before, it accounted for the size of the vertices but not the other fields
in the vertex_header struct, which caused memory corruption.
mesa: add EXT_geometry_shader4 and ARB_geometry_shader4 to extension list
mesa: account for geometry shader texture fetches in update_texture_state
glcpp: define extension macros for EXT/ARB_geometry_shader4
glsl: add builtins for EXT/ARB_geometry_shader4
glsl: add ir_emitvertex and ir_endprim instruction types

These correspond to the EmitVertex and EndPrimitive functions in GLSL.

v2 (Paul Berry <stereotype441@gmail.com>): Add stub implementations of
new pure visitor functions to i965's vec4_visitor and fs_visitor
classes.
glsl: lower gl_ClipDistanceIn to gl_ClipDistanceInMESA in lower_clip_distance

This corresponds to the lowering of gl_ClipDistance to gl_ClipDistanceMESA.
It converts the 2D array gl_ClipDistanceIn from EXT/ARB_geometry_shader4 to
a 1D array of vec4s, gl_ClipDistanceInMESA.
glsl: support compilation of geometry shaders via EXT/ARB_geometry_shader4

This commit adds all of the parsing and semantics for EXT/ARB_geometry_shader4,
including support for 2D arrays as inputs.

v2 (Paul Berry <stereotype441@gmail.com>): Adjust i965's
brw_link_shader() to pass the new is_geometry_shader argument to
do_set_program_inouts.  Add a few missing calls to
get_pipeline_stage().  Fix some signed/unsigned comparison warnings.
Fix handling of NULL consumer in assign_varying_locations().
mesa: Refactor copying of linked program data.

This patch creates a single function to copy the the UsesClipDistance
flag from gl_shader_program.Vert to gl_vertex_program.  Previously
this logic was duplicated in the i965-specific function
brw_link_shader() and the core mesa function _mesa_ir_link_shader().

This logic will have to be expanded to support geometry shaders, and I
don't want to have to update it in two separate places.
mesa: Copy linked program data for GS.

The documentation for gl_shader_program.Geom and gl_geometry_program
says that the former is copied to the latter at link time, but this
wasn't happening.  This patch causes _mesa_ir_link_shader() to perform
the copy, and updates comment accordingly.
glsl: Require geometry shader inputs to be arrays.
glsl/linker: Properly error check VS-GS linkage.

From the ARB_geometry_shader4 specification:

    A geometry shader may also read from an input varying variable declared
    with the "varying in" qualifiers. The value read will be the same value as
    written by the vertex shader for that varying variable. Since a geometry
    shader operates on primitives, each input varying variable needs to be
    declared as an array. Each element of such an array corresponds to a
    vertex of the primitive being processed. If the varying variable is
    declared as a scalar or matrix in the vertex shader, it will be a
    one-dimensional array in the geometry shader.

Therefore, a user-defined geometry shader input will always be an
array, and the *element type* of that array should match the type of
the corresponding vertex shader output.
glsl/linker: Properly pack GS input varyings.

Since geometry shader inputs are arrays (where the array index
indicates which vertex is being examined), varying packing needs to
treat them differently.
glsl: Modify varying packing to use a temporary exec_list.

This patch modifies lower_packed_varyings to store the packing code it
generates in a temporary exec_list, and then splice that list into the
shader's main() function when it's done.  This paves the way for
supporting geometry shader outputs, where we'll have to splice a clone
of the packing code before every call to EmitVertex().

As a side benefit, varying packing code is now emitted in the same
order for inputs and outputs; this should make debug output a little
easier to read.
glsl: Properly pack GS output varyings

In geometry shaders, outputs are consumed at the time of a call to
EmitVertex() (as opposed to all other shader types, where outputs are
consumed when the shader exits).  Therefore, when packing geometry
shader output varyings using lower_packed_varyings, we need to do the
packing at the time of the EmitVertex() call.

This patch accomplishes that by adding a new visitor class,
lower_packed_varyings_gs_splicer, which is responsible for splicing
the varying packing code into place wherever EmitVertex() is found.
st/mesa, glsl_to_tgsi: add support for geometry shaders

Note (Paul Berry <stereotype441@gmail.com>): I'm not sure I rebased
this correctly.  It appears that some amount of 2D array support was
added to tgsi after the patch was originally written.
WIP: make stuff safe to include from C++
i965: Stop including brw_vs.h from brw_vec4.h

This is backwards from what we are going to want in the long term, which is:

- brw_vec4.h declares general-purpose vec4 infrastructure needed by
  both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.

Note that at the moment brw_vec.h contains a fair amount of
VS-specific declarations--I plan to address that in a later patch.