Created attachment 120595 [details] hack patch When replaying traces from Bug 92229 with R600_DEBUG=llvm specified a crash will occur (on my system) in LLVMBuildInsertElement() because uninitialized value in Index argument is passed. That value originates from radeon_llvm_emit_prepare_cube_coords() function's coords[3] stack variable. At that time, opcode = TGSI_OPCODE_TEX target = TGSI_TEXTURE_CUBE so nothing ever sets coords[3], which is copied to the caller and eventually finds it way to llvm. Unfortunately I don't have any knowledge about that code, I hope somebody who knows more can take a look. A hack patch is attached but it's most likely wrong.
R600_DEBUG=llvm is currently known broken in many ways and should only be enabled by developers who want to fix it.
I believe this bug can also be triggered by radeonsi though, as it also calls radeon_llvm_emit_prepare_cube_coords(). When target == TGSI_TEXTURE_CUBE and opcode == TGSI_OPCODE_TXF, si_shader.c will take and use garbage value from that function. Unfortunately I don't have any radeonsi hardware to make a testcase to prove my point. It might also be difficult anyway due to nature of uinitialized variable bugs (it's likely to end up with a value that doesn't cause a crash).
(In reply to Grazvydas Ignotas from comment #2) > I believe this bug can also be triggered by radeonsi though, as it also > calls radeon_llvm_emit_prepare_cube_coords(). When target == > TGSI_TEXTURE_CUBE and opcode == TGSI_OPCODE_TXF, si_shader.c will take and > use garbage value from that function. You can't texelFetch() on a samplerCube.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.