Paul Berry <stereotype...@gmail.com> writes: > In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an > ir_rvalue_visitor), we failed to notice that since > lower_clip_distance_visitor overrides visit_leave(ir_assignment *), > ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called. > As a result, clip distance dereferences appearing directly on the > right hand side of an assignment (not in a subexpression) weren't > getting properly lowered. This caused an ir_dereference_variable node > to be left in the IR that referred to the old gl_ClipDistance > variable. However, since the lowering pass replaces gl_ClipDistance > with gl_ClipDistanceMESA, this turned into a dangling pointer when the > IR got reparented. > > Prior to the introduction of geometry shaders, this bug was unlikely > to arise, because (a) reading from gl_ClipDistance[i] in the fragment > shader was rare, and (b) when it happened, it was likely that it would > either appear in a subexpression, or be hoisted into a subexpression > by tree grafting. > > However, in a geometry shader, we're likely to see a statement like > this, which would trigger the bug: > > gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i];
These two are: Reviewed-by: Eric Anholt <e...@anholt.net> I didn't follow how gl_in[j].gl_ClipDistance[i] is a bare struct deref of the thing needing to be lowered, since it reads to me like there's an array and struct dereference first. But I assume that's just me not understanding how gl_in[] works.
pgpNolMERjthi.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
