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

--- Comment #7 from Connor Abbott <cwabbott0 at gmail.com> ---
Oh, and I forgot to mention:

If you do find that g->nodes[n2].reg is NO_REG, the next step would be to break
at the end of ra_simplify() (but make sure to stop at the last time the
breakpoint gets hit before the segfault using the stackoverflow post I linked
to) and print out the values of all the nodes (g->nodes[0], g->nodes[1], ...,
g->nodes[g->count - 1]). All the ones with .reg = NO_REG should also have
.in_stack = true. If one has .reg = NO_REG and .in_stack = false, then in
ra_simplify() we should have reached line 468, in which case we either push it
onto the stack (if pq_test() returns true) or considered it for optimistic
coloring (if pq_test() returns false). So if we finished the loop, then
progress == false and so no nodes were pushed on the stack and no nodes were
considered for optimistic coloring (see the places where we set progress =
true), so no nodes should have .reg = NO_REG and .in_stack = false when we
leave ra_simplify(). Then, in ra_select(), whenever we set .in_stack = false
(line 536) we also set .reg to something else (line 541) unless we run out of
registers in which case we bail out and then r300g will complain about running
out of registers. So it seems strange to me that that would happen, but also
the most likely explanation of why it's segfaulting.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140830/f8a57789/attachment.html>

Reply via email to