Seeing this also happening wit a bunch of piglit tests, both on r600g and softpipe.

e.g: 

stencil-drawpixels
scissor-copypixels
scissor-bitmap

What happens if you set GALLIUM_NOSSE=1?  I bet the tgsi->sse2 translator needs to be updated.

Yeah, just did some quick tests and setting GALLIUM_NOSSE=1 does indeed seem to fix it.

(In reply to comment #2)
> What happens if you set GALLIUM_NOSSE=1?  I bet the tgsi->sse2 translator needs
> to be updated.

I get a SIGTRAP on the demos which looks much the same with r600g and swrastg.

In case I am doing something lame/different here is my autogen -

./autogen.sh --prefix=/mypath --enable-debug --disable-egl --with-state-trackers=dri  --enable-gallium-r600 --enable-gallium-swrast --with-dri-drivers=r600,swrast
  

tgsi/tgsi_exec.c:1087:fetch_src_file_channel: Assertion `pos < (sizeof(mach->Inputs)/sizeof((mach->Inputs)[0]))' failed.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb727f700 (LWP 1777)]
_debug_assert_fail (expr=0xb7212dac "pos < (sizeof(mach->Inputs)/sizeof((mach->Inputs)[0]))", file=0xb7212a63 "tgsi/tgsi_exec.c", line=1087, function=0xb721328f "fetch_src_file_channel") at util/u_debug.c:285
285     }
(gdb) bt
#0  _debug_assert_fail (expr=0xb7212dac "pos < (sizeof(mach->Inputs)/sizeof((mach->Inputs)[0]))", file=0xb7212a63 "tgsi/tgsi_exec.c", line=1087, function=0xb721328f "fetch_src_file_channel") at util/u_debug.c:285
#1  0xb70dca3f in fetch_src_file_channel (mach=0x933a7c0, file=<value optimized out>, swizzle=0, index=0xbfc3e32c, index2D=0xbfc3e31c, chan=0xbfc3e3b0) at tgsi/tgsi_exec.c:1087
#2  0xb70dd68f in fetch_source (mach=0x933a7c0, chan=0xbfc3e3b0, reg=0x9325a30, chan_index=0, src_datatype=TGSI_EXEC_DATA_FLOAT) at tgsi/tgsi_exec.c:1313
#3  0xb70dda08 in exec_vector_binary (mach=0x933a7c0, inst=0x9325a00, op=0xb70dbc20 <micro_mul>, dst_datatype=TGSI_EXEC_DATA_FLOAT, src_datatype=TGSI_EXEC_DATA_FLOAT) at tgsi/tgsi_exec.c:2317
#4  0xb70e239a in exec_instruction (mach=0x933a7c0, inst=0xbfc3fd41, pc=0xbfc3e9b8) at tgsi/tgsi_exec.c:3249
#5  0xb70e3fd3 in tgsi_exec_machine_run (mach=0x933a7c0) at tgsi/tgsi_exec.c:4036
#6  0xb70ce740 in vs_exec_run_linear (shader=0x9325460, input=0x9326910, output=0x93269e4, constants=0x93302d0, const_size=0x9330350, count=1, input_stride=68, output_stride=68) at draw/draw_vs_exec.c:148
#7  0xb70c6964 in fetch_pipeline_generic (middle=0x933a730, fetch_info=<value optimized out>, prim_info=0xbfc3eac8) at draw/draw_pt_fetch_shade_pipeline.c:189
#8  0xb70c6b39 in fetch_pipeline_linear_run (middle=0x933a730, start=0, count=1, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:345
#9  0xb70c954e in vsplit_segment_simple_linear (vsplit=0x9337cc0, flags=0, istart=0, icount=1) at draw/draw_pt_vsplit_tmp.h:229
#10 0xb70c9668 in vsplit_run_linear (frontend=0x9337cc0, start=0, count=1) at draw/draw_split_tmp.h:61
#11 0xb70c4f94 in draw_pt_arrays (draw=0x932fe38, prim=0, start=0, count=1) at draw/draw_pt.c:113
#12 0xb70c51e2 in draw_vbo (draw=0x932fe38, info=0xbfc3ec34) at draw/draw_pt.c:480
#13 0xb70c53fb in draw_arrays_instanced (draw=0x932fe38, mode=0, start=0, count=1, startInstance=0, instanceCount=1) at draw/draw_pt.c:408
#14 0xb70c5446 in draw_arrays (draw=0x932fe38, prim=0, start=0, count=1) at draw/draw_pt.c:376
#15 0xb708ebc9 in st_feedback_draw_vbo (ctx=0x92d6a88, arrays=0x93253c8, prims=0x9325448, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=1) at state_tracker/st_draw_feedback.c:251
#16 0xb7087da4 in st_RasterPos (ctx=0x92d6a88, v=0xbfc3f18c) at state_tracker/st_cb_rasterpos.c:254
#17 0xb6f80be6 in rasterpos (x=0, y=0, z=-1, w=1) at main/rastpos.c:65
#18 0xb6f81038 in _mesa_RasterPos3f (x=0, y=0, z=-1) at main/rastpos.c:102
#19 0x0804950a in Display () at drawpix.c:55
#20 0xb78200ea in processWindowWorkList (window=0x91ca6a0) at glut_event.c:1307
#21 0xb7820dea in glutMainLoop () at glut_event.c:1358
#22 0x08049351 in main (argc=1764699694, argv=Cannot access memory at address 0x8
) at drawpix.c:357

The assertion failure should have been fixed with

commit 9f3c59a35093c61fb11aab6d3ed5cb45f2b8c2a7
Author: José Fonseca <jfonseca@vmware.com>
Date:   Thu Mar 3 19:15:24 2011 +0000

    tgsi: Update assert.
    
    Elements(mach->Inputs) is wrong now that mach->Inputs is dynamically
    allocated.

I'm not sure why the segfaults..

(In reply to comment #5)
> The assertion failure should have been fixed with
> 
> commit 9f3c59a35093c61fb11aab6d3ed5cb45f2b8c2a7
> Author: José Fonseca <jfonseca@vmware.com>
> Date:   Thu Mar 3 19:15:24 2011 +0000
> 
>     tgsi: Update assert.
> 
>     Elements(mach->Inputs) is wrong now that mach->Inputs is dynamically
>     allocated.
> 
> I'm not sure why the segfaults..

Yes, this does fix it with GALLIUM_NOSSE=1.

I hadn't updated mesa when I tested.

Without GALLIUM_NOSSE=1 the bug is still there.

(In reply to comment #6)

> Without GALLIUM_NOSSE=1 the bug is still there.

This is tunnel with swrastg and current mesa using sse.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7237700 (LWP 7902)]
fs_sse_run (base=0x83fd650, machine=0x83590d0, quad=0x83a5910) at sp_fs_sse.c:164
164                    memcpy(quad->output.color[cbuf],
(gdb) bt
#0  fs_sse_run (base=0x83fd650, machine=0x83590d0, quad=0x83a5910) at sp_fs_sse.c:164
#1  0xb6ec3efb in shade_quads (qs=0x82ada68, quads=0x83a7cd0, nr=5) at sp_quad_fs.c:77
#2  0xb6ec7a6e in flush_spans (setup=0x83a58a8) at sp_setup.c:243
#3  0xb6ec8050 in subtriangle (setup=0x3f298a88, eleft=0x83a58ec, eright=0x83a58d4, lines=17) at sp_setup.c:751
#4  0xb6ec899c in sp_setup_tri (setup=0x83a58a8, v0=0x8473ce0, v1=0x8473ca0, v2=0x8473d20) at sp_setup.c:841
#5  0xb6ec0a10 in sp_vbuf_draw_arrays (vbr=0x82a3790, start=0, nr=12) at sp_prim_vbuf.c:427
#6  0xb70d9791 in draw_pt_emit_linear (emit=0x82a8730, vert_info=0xbf9b368c, prim_info=0xbf9b36c8) at draw/draw_pt_emit.c:265
#7  0xb707eacb in fetch_pipeline_generic (middle=0x82a8698, fetch_info=<value optimized out>, prim_info=0xbf9b36c8) at draw/draw_pt_fetch_shade_pipeline.c:168
#8  0xb707ec09 in fetch_pipeline_linear_run (middle=0x82a8698, start=12, count=12, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:345
#9  0xb708161e in vsplit_segment_simple_linear (vsplit=0x83740e8, flags=0, istart=12, icount=12) at draw/draw_pt_vsplit_tmp.h:229
#10 0xb7081738 in vsplit_run_linear (frontend=0x83740e8, start=12, count=12) at draw/draw_split_tmp.h:61
#11 0xb707d064 in draw_pt_arrays (draw=0x836dfe0, prim=5, start=12, count=12) at draw/draw_pt.c:113
#12 0xb707d2b2 in draw_vbo (draw=0x836dfe0, info=0xbf9b3ca4) at draw/draw_pt.c:480
#13 0xb6ebfe25 in softpipe_draw_vbo (pipe=0x82a18b8, info=0xbf9b3ca4) at sp_draw_arrays.c:143
#14 0xb6f6869b in st_draw_vbo (ctx=0x83aba88, arrays=0x83ee748, prims=0x83ed09c, nr_prims=5, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=59) at state_tracker/st_draw.c:741
#15 0xb70285a2 in vbo_exec_vtx_flush (exec=0x83ecf28, keepUnmapped=1 '\001') at vbo/vbo_exec_draw.c:389
#16 0xb701fa14 in vbo_exec_FlushVertices_internal (exec=0x83ecf28, unmap=136 '\210') at vbo/vbo_exec_api.c:543
#17 0xb70218c7 in vbo_exec_FlushVertices (ctx=0x83aba88, flags=1) at vbo/vbo_exec_api.c:990
#18 0xb6f50ea1 in _mesa_BindTexture (target=3553, texName=2) at main/texobj.c:1086
#19 0x0804a164 in draw () at tunnel.c:429
#20 0xb77d80ea in processWindowWorkList (window=0x829f6a0) at glut_event.c:1307
#21 0xb77d8dea in glutMainLoop () at glut_event.c:1358
#22 0x08049baa in main (ac=1, av=0xbf9b4144) at tunnel.c:540

I've commited a workaround:

commit 6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
Author: José Fonseca <jfonseca@vmware.com>
Date:   Fri Mar 4 14:54:24 2011 +0000

    tgsi: Disable SSE2 code generation.
    
    It's broken now that tgsi_exec_machine::Inputs/Ouputs are pointers.
    
    Temporary if anybody still cares about tgsi_sse2.c. Permanent otherwise.


I think if people care about performance they should enable LLVM support.

(In reply to comment #8)
> I've commited a workaround:
> 
> commit 6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
> Author: José Fonseca <jfonseca@vmware.com>
> Date:   Fri Mar 4 14:54:24 2011 +0000
> 
>     tgsi: Disable SSE2 code generation.
> 
>     It's broken now that tgsi_exec_machine::Inputs/Ouputs are pointers.
> 
>     Temporary if anybody still cares about tgsi_sse2.c. Permanent otherwise.
> 
> 
> I think if people care about performance they should enable LLVM support.

Working, but I get a couple of these to stderr. 

draw/draw_vs_sse.c:203:draw_create_vs_sse: error: tgsi_emit_sse2() failed, falling back to interpreter

(In reply to comment #9)
> Working, but I get a couple of these to stderr. 
> 
> draw/draw_vs_sse.c:203:draw_create_vs_sse: error: tgsi_emit_sse2() failed,
> falling back to interpreter

It's not really error. It's really just a performance warning, and it should probably be silenced now that tgsi_emit_sse2 became a no-op.