Bug 79504 - LLVM error on fragment shader
Summary: LLVM error on fragment shader
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-01 12:26 UTC by Kyle Blake
Modified: 2016-02-12 03:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
fragment shader (6.07 KB, text/plain)
2014-06-01 12:26 UTC, Kyle Blake
Details
simple vertex shader (163 bytes, text/plain)
2014-06-01 12:27 UTC, Kyle Blake
Details
full error log (3.92 KB, text/plain)
2014-06-01 12:27 UTC, Kyle Blake
Details
output of glxinfo (57.51 KB, text/plain)
2014-06-01 12:28 UTC, Kyle Blake
Details
testcase (2.44 KB, text/plain)
2014-06-02 07:58 UTC, Kyle Blake
Details
stderr output with R600_DEBUG=ps (81.58 KB, text/plain)
2014-06-02 09:38 UTC, Kyle Blake
Details
full testcase (6.32 KB, text/plain)
2014-06-06 08:38 UTC, Kyle Blake
Details
fragment shader w/ correct switch labels (6.08 KB, text/plain)
2014-06-15 05:53 UTC, Kyle Blake
Details

Description Kyle Blake 2014-06-01 12:26:46 UTC
Created attachment 100230 [details]
fragment shader

After compiling the attached shader and making it current, calling glClear() causes the process to crash with this error:

    LLVM ERROR: Cannot select: 0x314a010: v16f32 = bitcast 0x3185250 [ORD=347] [ID=224]
      0x3185250: v16i32 = BUILD_VECTOR 0x3153680, 0x3153780, 0x3153880, 0x3153980, 0x3187b70, 0x3187970, 0x3097a00, 0x3097800, 0x3097600, 0x3097400, 0x3097200, 0x3097000, 0x3096e00, 0x3096c00, 0x3185550, 0x314b520 [ORD=347] [ID=222]
        ... <snip> ...

(full error attached)

I'm using the latest git version (3fc72f2ec601cb758d69cf2933dd6268d1a80c5b).
Comment 1 Kyle Blake 2014-06-01 12:27:16 UTC
Created attachment 100231 [details]
simple vertex shader
Comment 2 Kyle Blake 2014-06-01 12:27:50 UTC
Created attachment 100232 [details]
full error log
Comment 3 Kyle Blake 2014-06-01 12:28:57 UTC
Created attachment 100233 [details]
output of glxinfo
Comment 4 Michel Dänzer 2014-06-02 06:55:18 UTC
Can you also attach code or post instructions for reproducing the problem with this fragment shader?
Comment 5 Kyle Blake 2014-06-02 07:58:33 UTC
Created attachment 100273 [details]
testcase

Compile with gcc test.c -lGL -lglut. Depends on freeglut for context creation. Requires raycast.vert and raycast.frag to be in the working directory.
Comment 6 Michel Dänzer 2014-06-02 08:47:48 UTC
Thanks, but unfortunately, this results in an assertion failure during glCompileShader() for me.

Can you attach the stderr output from running this on your end with R600_DEBUG=ps?
Comment 7 Kyle Blake 2014-06-02 09:38:58 UTC
Created attachment 100277 [details]
stderr output with R600_DEBUG=ps
Comment 8 Michel Dänzer 2014-06-03 03:05:24 UTC
I can reproduce the shader compilation failure with LLVM 3.4, but it seems to compile fine here with current LLVM Git/SVN.
Comment 9 Kyle Blake 2014-06-03 08:06:53 UTC
Yeah, it compiles with LLVM git here. However, when run, it locks up X for a few seconds, displays some snow, and then locks up the kernel. I'm still working on tracking down a minimal testcase for it, but at least replacing the main while loop with this:

    child = texelFetch(octree, int(root)).x;

still allows the bug to manifest. Setting child to a constant value does not. Setting the output of the entire shader to texelFetch(octree, int(root)).x at the top and immediately returning displays the correct image, so the texture is correct.
Comment 10 Kyle Blake 2014-06-06 08:38:25 UTC
Created attachment 100512 [details]
full testcase

Sorry for the delay. Attached is a new test case that actually uses the shaders. When it calls glDrawElements(), everything goes to hell, triggering random segfault, graphics memory corruption, and kernel panics.
Comment 11 Michel Dänzer 2014-06-06 09:56:14 UTC
I run into the assertion failure below in the GLSL compiler. That should be addressed first.

test2: ../../../src/glsl/ir_validate.cpp:436: virtual ir_visitor_status {anonymous}::ir_validate::visit_leave(ir_expression*): Assertion `ir->operands[0]->type == ir->operands[1]->type' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff75973a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff75973a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff759a4c8 in __GI_abort () at abort.c:89
#2  0x00007ffff75904c6 in __assert_fail_base (fmt=0x7ffff76c7668 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x7ffff44c6b40 "ir->operands[0]->type == ir->operands[1]->type", file=file@entry=0x7ffff44ee9d8 "../../../src/glsl/ir_validate.cpp", line=line@entry=436, 
    function=function@entry=0x7ffff44efd80 <(anonymous namespace)::ir_validate::visit_leave(ir_expression*)::__PRETTY_FUNCTION__> "virtual ir_visitor_status {anonymous}::ir_validate::visit_leave(ir_expression*)") at assert.c:92
#3  0x00007ffff7590572 in __GI___assert_fail (assertion=0x7ffff44c6b40 "ir->operands[0]->type == ir->operands[1]->type", file=0x7ffff44ee9d8 "../../../src/glsl/ir_validate.cpp", line=436, 
    function=0x7ffff44efd80 <(anonymous namespace)::ir_validate::visit_leave(ir_expression*)::__PRETTY_FUNCTION__> "virtual ir_visitor_status {anonymous}::ir_validate::visit_leave(ir_expression*)") at assert.c:101
#4  0x00007ffff42e57b1 in (anonymous namespace)::ir_validate::visit_leave (this=<optimized out>, ir=<optimized out>) at ../../../src/glsl/ir_validate.cpp:436
#5  0x00007ffff42e2fdf in ir_assignment::accept (this=0xaaa360, v=0x7fffffffe420) at ../../../src/glsl/ir_hv_accept.cpp:308
#6  0x00007ffff42e2a16 in visit_list_elements (v=v@entry=0x7fffffffe420, l=l@entry=0xaa95e8, statement_list=statement_list@entry=true) at ../../../src/glsl/ir_hv_accept.cpp:56
#7  0x00007ffff42e3204 in ir_if::accept (this=0xaa95c0, v=0x7fffffffe420) at ../../../src/glsl/ir_hv_accept.cpp:391
#8  0x00007ffff42e2a16 in visit_list_elements (v=v@entry=0x7fffffffe420, l=l@entry=0x732698, statement_list=statement_list@entry=true) at ../../../src/glsl/ir_hv_accept.cpp:56
#9  0x00007ffff42e2b79 in ir_function_signature::accept (this=0x732650, v=0x7fffffffe420) at ../../../src/glsl/ir_hv_accept.cpp:116
#10 0x00007ffff42e2a16 in visit_list_elements (v=v@entry=0x7fffffffe420, l=l@entry=0x7324f8, statement_list=statement_list@entry=false) at ../../../src/glsl/ir_hv_accept.cpp:56
#11 0x00007ffff42e2be7 in ir_function::accept (this=0x7324d0, v=0x7fffffffe420) at ../../../src/glsl/ir_hv_accept.cpp:128
#12 0x00007ffff42e2a16 in visit_list_elements (v=v@entry=0x7fffffffe420, l=l@entry=0x6cc4a0, statement_list=statement_list@entry=true) at ../../../src/glsl/ir_hv_accept.cpp:56
#13 0x00007ffff42e293f in ir_hierarchical_visitor::run (this=this@entry=0x7fffffffe420, instructions=instructions@entry=0x6cc4a0) at ../../../src/glsl/ir_hierarchical_visitor.cpp:309
#14 0x00007ffff42e7ae0 in validate_ir_tree (instructions=0x6cc4a0) at ../../../src/glsl/ir_validate.cpp:817
#15 0x00007ffff42d3d2b in _mesa_glsl_compile_shader (ctx=ctx@entry=0x7ffff7fd4010, shader=shader@entry=0x6c1ea0, dump_ast=dump_ast@entry=false, dump_hir=dump_hir@entry=false)
    at ../../../src/glsl/glsl_parser_extras.cpp:1470
#16 0x00007ffff41aa481 in compile_shader (ctx=0x7ffff7fd4010, shaderObj=<optimized out>) at ../../../src/mesa/main/shaderapi.c:850
#17 0x0000000000401c4f in create_shader ()
#18 0x0000000000402073 in init_resources ()
#19 0x00000000004027ec in main ()
Comment 12 Tapani Pälli 2014-06-06 12:11:12 UTC
FYI there might be a bug in fragment shader here (not sure if I read the spec correctly though). Each switch case in fragment shader should have 'u' after the number '1u', '2u' and so on to use same type as the switch has, otherwise it defaults to signed in GLSL.

But yetp, there's Mesa bug also, it should probably do compile error here or maybe just warning and set the same type when doing AST->HIR, but this is a separate bug.
Comment 13 Tapani Pälli 2014-06-06 12:13:51 UTC
I filed bug #79724 to track the AST->HIR problems.
Comment 14 Tapani Pälli 2014-06-12 10:02:51 UTC
FYI I've sent a fix to tackle the Mesa problem. However the test application here is still broken anyway, it uses GLSL 330 which does not have support for implicit int->uint type conversion. This means the switch case labels need to be changed as unsigned or you should explicitly convert yourself (int typei = int(type); and use typei as the switch init-expression instead of type).
Comment 15 Kyle Blake 2014-06-15 05:53:11 UTC
Created attachment 101078 [details]
fragment shader w/ correct switch labels

Fixed fragment shader to use unsigned case labels. Crashing bug still occurs.
Comment 16 Timothy Arceri 2016-02-11 05:09:20 UTC
Test program no longer hits any issues in the glsl compiler, and program runs on i965. The program says My First Triangle but has a couple of squares, I'm assuming that's just an issue with the program rather than Mesa.

Reassigning to radeonsi for further testing.
Comment 17 Michel Dänzer 2016-02-12 03:32:46 UTC
Thanks guys. Works for me with radeonsi as well now, if it still doesn't for you Kyle, please reopen with current glxinfo output.
Comment 18 Kyle Blake 2016-02-12 03:50:52 UTC
Confirming that it works for me.


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.