Summary: | LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven | ||
---|---|---|---|
Product: | Mesa | Reporter: | Bruno Jacquet (Xaapyks) <maxijac> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | Other | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
backtrace
Possible fix |
Description
Bruno Jacquet (Xaapyks)
2012-10-26 17:44:36 UTC
I was unclear about LLVM: I am using the llvm glsl backend when I trigger this error. I saw this yesterday after rebuilding Mesa and running nexuiz. Running again worked without error. This is the second time I've seen it, the first was a couple of weeks ago, again after a rebuild of mesa this time with etqw. I couldn't reproduce, but did get more output - LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad Stack dump: 0. Running pass 'Function Pass Manager' on module 'tgsi'. 1. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@main' I am using llvm 3.1 on HD4890. Does the environment variable DRAW_USE_LLVM=0 work around the problem as well? Can you get a backtrace for the crash? I could reproduce the crash with DRAW_USE_LLVM=0. I did not manage to get a backtrace. I probably need to recompile LLVM with debug. I'll do it when I have time. So I recompiled LLVM with debug symbols but I can't seem to get a backtrace... Looks like it's because the libGL is loaded via dlopen or something like that. Any hints on how to procedd with gdb ? I tried to use symbol-file and load libLLVM then setting a breakpoint where it prints the error but is didn't stop when it ran this code... (In reply to comment #5) How are you specifying the breakpoint location? IME it's most reliable to specify the source code file and line, e.g. foobar.c:42 (In reply to comment #6) This is what I did and it never halted on the breakpoint. I'll try again when I have time. (In reply to comment #7) > This is what I did and it never halted on the breakpoint. After the problem occurs, does 'info breakpoints' show that gdb was able to actually resolve the breakpoint location? Created attachment 69326 [details]
backtrace
Finally got it! this was checked with llvm 3.1 and mesa b3921e1f53833420e0a0fd581f741744e7957a05 Created attachment 69334 [details]
Possible fix
This is a strange bug. There must be a race condition somewhere. Does this patch help? If it doesn't, can you reproduce this with an LLVM 3.2 tree:
git fetch git://people.freedesktop.org/~tstellar/llvm master
(In reply to comment #12) > Created attachment 69334 [details] > Possible fix > > This is a strange bug. There must be a race condition somewhere. Does this > patch help? If it doesn't, can you reproduce this with an LLVM 3.2 tree: > > git fetch git://people.freedesktop.org/~tstellar/llvm master I should add you need to build the branch of LLVM with --enable-experimental-targets=AMDGPU (In reply to comment #12) > Created attachment 69334 [details] > Possible fix > > This is a strange bug. There must be a race condition somewhere. Does this > patch help? If it doesn't, can you reproduce this with an LLVM 3.2 tree: > > git fetch git://people.freedesktop.org/~tstellar/llvm master With your patch applied I can't seem to reproduce the crash. Not seen in a while with vanilla mesa, closing. |
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.