Bug 58384

System Environment:
--------------------------
Arch:           x86_64
Platform:       Ivybridge
Libdrm:		(master)libdrm-2.4.40-3-g0980633afd9c7eecc0c75ef3bea4d3c6b7aa1898
Mesa:		(master)4f91f8dd6057b73d05454fc626985183d00e5236
Xserver:(master)xorg-server-1.13.0-188-gb51a1bd2766e7dc975ca8f1cacc3f8bd0e1a68a3
Xf86_video_intel:(master)2.20.16
Cairo:		(master)9d9aa04b60e24542b6b2a4c6bf87115db7736c2f
Libva:		(staging)b8d3cf092c9b07cfd909552a3c160b7db3b5a91d
Libva_intel_driver:(staging)82a4a3915821dd2a302ca87d21dfcd945f2500af
Kernel:	(drm-intel-nightly) 70880564238362d96181fb54d0edf1a5bf5b24cc

Bug detailed description:
-------------------------
It segfaults on Ironlake,Sandybridge,Ivybridge,Haswell with mesa master branch.It works well on mesa 9.0 branch.

max_values(advanced.fragmentProgram.GL_MAX_PROGRAM_LOCAL_PARAMETERS) also segfaults on ivybridge, and has same bisect commit.

Bisect show: 456dbcc3377ee23dbeffa4da02a4d80a8519bb62 is the first bad commit.
commit 456dbcc3377ee23dbeffa4da02a4d80a8519bb62
Author:     Eric Anholt <eric@anholt.net>
AuthorDate: Mon Dec 3 19:59:55 2012 -0800
Commit:     Eric Anholt <eric@anholt.net>
CommitDate: Fri Dec 14 15:17:59 2012 -0800

    i965/fs: Before reg alloc, schedule instructions to reduce live ranges.

    This came from an idea by Ben Segovia.  16-wide pixel shaders are very
    important for latency hiding on i965, so we want to try really hard to
    get them.  If scheduling an instruction makes some set of instructions
    available, those are probably the ones that make the instruction's
    result dead.  By choosing those first, we'll have a tendency to reduce
    the amount of live data as opposed to creating more.

    Previously, we were sometimes getting this behavior out of the
    scheduler, which was what produced the scheduler's original performance
    wins on lightsmark.  Unfortunately, that was mostly an accident of the
    lame instruction latency information that I had, which made it
    impossible to fix the actual scheduling for performance.  Now that we've
    fixed the scheduling for setup for register allocation, we can safely
    update the latency parameters for the final schedule.

    In shader-db, we lose 37 16-wide shaders, but gain 90 new ones.  4
    shaders that were spilling change how many registers spill, for a
    reduction of 70/3899 instructions.

    v2: Simplify the new loop.

(gdb) bt
#0  brw_wm_fs_emit (brw=0x2ed1d00, c=0x32b07a0, fp=0x32d3fa0, prog=0x0, final_assembly_size=0x7fffffffccac) at brw_fs.cpp:2609
#1  0x00007ffff6735c21 in do_wm_prog (brw=0x2ed1d00, prog=0x0, fp=0x32d3fa0, key=0x7fffffffccf0) at brw_wm.c:175
#2  0x00007ffff673643d in brw_upload_wm_prog (brw=0x2ed1d00) at brw_wm.c:489
#3  0x00007ffff6714d82 in brw_upload_state (brw=0x2ed1d00) at brw_state_upload.c:500
#4  0x00007ffff66d87c7 in brw_try_draw_prims (max_index=<optimized out>, min_index=<optimized out>, ib=0x2f23294, nr_prims=49146720, prim=0x2f2327c, arrays=<optimized out>,
    ctx=0x2ed1d00) at brw_draw.c:498
#5  brw_draw_prims (ctx=0x2ed1d00, prim=0x2f2327c, nr_prims=49146720, ib=0x2f23294, index_bounds_valid=<optimized out>, min_index=0, max_index=3, tfb_vertcount=0x0)
    at brw_draw.c:585
#6  0x00007ffff623a6f5 in vbo_exec_vtx_flush (exec=0x2f229e8, keepUnmapped=1 '\001') at ../../../src/mesa/vbo/vbo_exec_draw.c:400
#7  0x00007ffff622b9ac in vbo_exec_FlushVertices_internal (exec=0x2f229e8, unmap=<optimized out>) at ../../../src/mesa/vbo/vbo_exec_api.c:551
#8  0x00007ffff623817c in vbo_exec_FlushVertices (ctx=0x2ed1d00, flags=<optimized out>) at ../../../src/mesa/vbo/vbo_exec_api.c:1249
#9  0x00007ffff6187c30 in _mesa_set_enable (ctx=0x2ed1d00, cap=34820, state=0 '\000') at ../../../src/mesa/main/enable.c:886
#10 0x00000000007211f7 in oglConf::max_values::genericProgramEnvParametersTest(bool) ()
#11 0x0000000000722792 in MaxValuesExec(testParameters*) ()
#12 0x00000000016b0aa9 in callFunctionHandleExceptionsInner(long (*)(testParameters*), testParameters*, char*) ()
#13 0x00000000016b0bff in callFunctionHandleExceptions(long (*)(testParameters*), testParameters*) ()
#14 0x00000000016af891 in DriverExec(long (*)(testParameters*), testParameters*) ()
#15 0x00000000015e63b5 in Driver(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<driverRec*, std::allocator<driverRec*> > const&, std::vector<boost::shared_ptr<PrePostTestAction>, std::allocator<boost::shared_ptr<PrePostTestAction> > > const&, std::vector<boost::shared_ptr<PrePostTestcaseAction>, std::allocator<boost::shared_ptr<PrePostTestcaseAction> > > const&) ()
#16 0x00000000015e6e68 in (anonymous namespace)::MyMessagePump::idle() ()
#17 0x00000000015b7e70 in MessagePump::process_messages() ()
#18 0x00000000015e53dc in ExecutionManager::execute_schedules() ()
#19 0x00000000015851e7 in tkShellExecute(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&) ()
#20 0x0000000000428265 in main ()

Visual Report:
ID      |ACCELERA|DB      |REND_T  |SURF_T  |C_BUF_T |BUF_S   |RED_S   |
     142|       1|       1|      gl|  wipbpx|    rgba|      32|       8|

GREEN_S |BLUE_S  |ALPHA_S |DEPTH_S |STENC_S |ACCUM_S |SPL_BUF |SAMPLES |
       8|       8|       8|      24|       8|       0|       0|       0|

SRGB    |TEX_RGB |TEX_RGBA|CAVEAT  |SWAP    |M_PBUF_W|M_PBUF_H|M_PBUF_P
       0|       0|       0|    none|   undef|       0|       0|       0

Reproduce steps:
----------------
1. start X
2. ./oglconform -z -suite all -v 2 -minFmt -test max_values \
advanced.fragmentProgram.GL_MAX_PROGRAM_ENV_PARAMETERS_ARB