https://bugs.freedesktop.org/show_bug.cgi?id=82828
--- Comment #5 from Pavel Ondračka pavel.ondracka@email.cz --- Created attachment 105451 --> https://bugs.freedesktop.org/attachment.cgi?id=105451&action=edit full backtrace from piglit crash
(In reply to comment #4)
All the crashes are in the same place, right?
Can you run it under gdb and print out n2 and the contents of g->nodes[n].adjacency_list (it's an array with g->nodes[n].adjacency_count elements) after the segfault? How about the former before the ra_simplify() call in the ra_allocate() call that's segfaulting? (If you don't know how to do this, see http://stackoverflow.com/questions/2956889/how-to-set-a-counter-for-a-gdb- breakpoint)
I'm guessing that it's segfaulting because n2 is some bogus value. n2 comes from the adjacency_list, which is something generated before the allocator actually runs by code I didn't touch and then never modified afterward, and the code that's segfaulting wasn't modified by the commit in question, so the two most likely options I see are that either this is exposing a bug somewhere else (like in r300g) or the new ra_simplify() is somehow corrupting the adjacency_list. I don't know how r300g sets up the register conflicts and register classes, though, so I can't guess why it works fine on i965 but fails for r300g.
OK, so not sure if I know what I'm doing but selecting one random crashing piglit test
/bin/shader_runner tests/shaders/glsl-fs-loop-continue.shader_test -auto
Program received signal SIGSEGV, Segmentation fault. 0xb76391a9 in ra_select (g=0x80c2058) at ../../src/mesa/program/register_allocate.c:525 525 BITSET_TEST(g->regs->regs[r].conflicts, g->nodes[n2].reg)) {
print n2 $2 = 0
print n $7 = 1
print g->nodes[n].adjacency_count $1 = 3
print g->nodes[n].adjacency_list $3 = (unsigned int *) 0x80c1b58
print g->nodes[n].adjacency_list[0] $4 = 1
print g->nodes[n].adjacency_list[1] $5 = 0
print g->nodes[n].adjacency_list[2] $6 = 2
full backtrace attached.