[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 3089 bytes --]

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

            Bug ID: 92709
           Summary: "LLVM triggered Diagnostic Handler: unsupported call
                    to function ldexpf in main" when starting race in
                    stuntrally
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: haagch@frickel.club
        QA Contact: dri-devel@lists.freedesktop.org

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M] (rev ff)

llvm-svn 251500 (but happened at least since 251005)
mesa git
stuntrally 2.6

Here is a trace (167 mb compressed):
http://haagch.frickel.club/files/stuntrally.trace.xz
It replays fine on intel, but produces said exception on radeonsi:

[...]
LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main
apitrace: warning: caught signal 11
601245: error: caught an unhandled exception
glretrace+0x23c99c
/usr/lib/libpthread.so.0+0x10d5f
/usr/lib/libLLVM.so.3.8+0xa96976
/usr/lib/libLLVM.so.3.8:
_ZNK4llvm14TargetLowering11LowerCallToERNS0_16CallLoweringInfoE+0x1406
/usr/lib/libLLVM.so.3.8:
_ZN4llvm19SelectionDAGBuilder14lowerInvokableERNS_14TargetLowering16CallLoweringInfoEPKNS_10BasicBlockE+0x38b
/usr/lib/libLLVM.so.3.8:
_ZN4llvm19SelectionDAGBuilder11LowerCallToENS_17ImmutableCallSiteENS_7SDValueEbPKNS_10BasicBlockE+0x62e
/usr/lib/libLLVM.so.3.8:
_ZN4llvm19SelectionDAGBuilder9visitCallERKNS_8CallInstE+0x9f
/usr/lib/libLLVM.so.3.8:
_ZN4llvm19SelectionDAGBuilder5visitERKNS_11InstructionE+0x33
/usr/lib/libLLVM.so.3.8:
_ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorIKNS_11InstructionEEES4_Rb+0x37
/usr/lib/libLLVM.so.3.8:
_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE+0x38f
/usr/lib/libLLVM.so.3.8:
_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE+0x471
/usr/lib/libLLVM.so.3.8:
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x289
/usr/lib/libLLVM.so.3.8: _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x2a
/usr/lib/libLLVM.so.3.8:
_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x300
/usr/lib/libLLVM.so.3.8+0x1205e7e
/usr/lib/libLLVM.so.3.8: LLVMTargetMachineEmitToMemoryBuffer+0xa8
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x591aaf
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x50f0ea
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x50fe37
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x51a894
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x51b405
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x517ade
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x3a4e16
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x1fe042
/usr/lib/xorg/modules/dri/radeonsi_dri.so+0x1cd399
glretrace+0xd51c9
glretrace+0xbd1c
glretrace+0xc37b
glretrace+0x7b04
/usr/lib/libc.so.6: __libc_start_main+0xef
glretrace: _start+0x28

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4501 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 792 bytes --]

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

Michel Dänzer <michel@daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arsenm2@gmail.com,
                   |                            |tstellar@gmail.com

--- Comment #1 from Michel Dänzer <michel@daenzer.net> ---
This happens since Mesa commit d72a26ec ("radeonsi: don't emit AMDGPU
intrinsics for EX2, ROUND, TRUNC") because the LLVM function
LibCallSimplifier::optimizeExp2() replaces the llvm.exp2.f32 call (which could
be handled by the AMDGPU backend AFAICT) with an ldexpf one.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2313 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 727 bytes --]

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

--- Comment #2 from Matt Arsenault <arsenm2@gmail.com> ---
(In reply to Michel Dänzer from comment #1)
> This happens since Mesa commit d72a26ec ("radeonsi: don't emit AMDGPU
> intrinsics for EX2, ROUND, TRUNC") because the LLVM function
> LibCallSimplifier::optimizeExp2() replaces the llvm.exp2.f32 call (which
> could be handled by the AMDGPU backend AFAICT) with an ldexpf one.

This is one of those annoying cases where ldexp doesn't have an equivalent
generic ISD node. We should probably add one and use it for the libcall and
handle it like most of the other math LibFuncs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 850 bytes --]

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

Michel Dänzer <michel@daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nhaehnle@gmail.com

--- Comment #3 from Michel Dänzer <michel@daenzer.net> ---
(In reply to Matt Arsenault from comment #2)
> This is one of those annoying cases where ldexp doesn't have an equivalent
> generic ISD node. We should probably add one and use it for the libcall and
> handle it like most of the other math LibFuncs.

Do you think you or someone else (Nicolai?) can look into this soon? Otherwise,
we probably need to to stop using this from Mesa again for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2483 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 395 bytes --]

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

--- Comment #4 from Nicolai Hähnle <nhaehnle@gmail.com> ---
Sure, I can look into that.

Matt, just to clarify: You mean adding a generic ISD::FLDEXP to ISDOpcodes.h,
together with assorted tests and changes in the generic CodeGen infrastructure,
right?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1330 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 731 bytes --]

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

--- Comment #5 from Matt Arsenault <arsenm2@gmail.com> ---
(In reply to Nicolai Hähnle from comment #4)
> Sure, I can look into that.
> 
> Matt, just to clarify: You mean adding a generic ISD::FLDEXP to
> ISDOpcodes.h, together with assorted tests and changes in the generic
> CodeGen infrastructure, right?

Yes. This should be pretty trivial to do.

Alternatively, it would probably be better to have an ldexp llvm intrinsic
(which would also have the corresponding ISD::FLDEXP). It seems bizarre that an
llvm intrinsic would ever be changed to something involving a library call.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1746 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 652 bytes --]

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

--- Comment #6 from Michel Dänzer <michel@daenzer.net> ---
(In reply to Matt Arsenault from comment #5)
> It seems bizarre that an llvm intrinsic would ever be changed to something
> involving a library call.

I think the exp2 -> ldexpf transform is rather questionable for us anyway,
since we have a native exp2 instruction, isn't it? Maybe we just don't want to
use the LibCallSimplifier pass? The comment at the top of SimplifyLibCalls.cpp
kind of sounds like "this is not the pass you're looking for"...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1672 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 811 bytes --]

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

--- Comment #7 from Matt Arsenault <arsenm2@gmail.com> ---
(In reply to Michel Dänzer from comment #6)
> (In reply to Matt Arsenault from comment #5)
> > It seems bizarre that an llvm intrinsic would ever be changed to something
> > involving a library call.
> 
> I think the exp2 -> ldexpf transform is rather questionable for us anyway,
> since we have a native exp2 instruction, isn't it? Maybe we just don't want
> to use the LibCallSimplifier pass? The comment at the top of
> SimplifyLibCalls.cpp kind of sounds like "this is not the pass you're
> looking for"...

We do want this. ldexp is a full rate instruction, and exp2 is a quarter rate
instruction.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1896 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]

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

--- Comment #8 from Nicolai Hähnle <nhaehnle@gmail.com> ---
Created attachment 119396
  --> https://bugs.freedesktop.org/attachment.cgi?id=119396&action=edit
Patch for LLVM

Here's a first cut at a patch that adds an llvm.ldexp.* intrinsic, so that
LibCallSimplifier generates that instead of the call to ldexpf, and codegen is
able to select the right instruction. With this change, Christoph's trace runs
to completion without errors.

See also http://reviews.llvm.org/D14327

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1809 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 519 bytes --]

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

Michel Dänzer <michel@daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kai@dev.carbon-project.org

--- Comment #9 from Michel Dänzer <michel@daenzer.net> ---
*** Bug 92913 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2308 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 825 bytes --]

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

Michel Dänzer <michel@daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Michel Dänzer <michel@daenzer.net> ---
Module: Mesa
Branch: master
Commit: d09463193608009fa42e046b1fc144435d3533f6
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d09463193608009fa42e046b1fc144435d3533f6

Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Nov 19 11:30:21 2015 +0900

radeon/llvm: Use llvm.AMDIL.exp intrinsic again for now

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2716 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 5212 bytes --]

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

higuita@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #11 from higuita@gmx.net ---
i'm getting this error using mesa 11.1.0-rc2 and llvm 3.7.0 when starting
WarThunder:

 16:07:32 /mnt/SteamOS/SteamApps/common/War Thunder/$  ./aces 
[S_API FAIL] SteamAPI_Init() failed; no appID found.
Either launch the game from Steam, or put the file steam_appid.txt containing
the correct appID in your game folder.
LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main
Segmentation fault (core dumped)


This after building mesa with debug enabled, as before enabling it, i didn't
see anything.

>From this bug, this was fixed and checking the mesa source, it is using
"llvm.AMDIL.exp"... yet i get the same error message.Maybe this patch was not
enough?

Here is the gdb backtrace:


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0ce26c287e in __strstr_sse2 () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f0ce427f200 (LWP 13990))]
(gdb) bt
#0  0x00007f0ce26c287e in __strstr_sse2 () from /lib64/libc.so.6
#1  0x0000000000949934 in ?? ()
#2  0x00000000007c6235 in ?? ()
#3  0x0000000001895647 in ?? ()
#4  0x0000000001dae23c in ?? ()
#5  <signal handler called>
#6  0x00007f0cd601977e in ?? () from /usr/lib64/../lib64/libLLVM.so.3.7
#7  0x00007f0cd6043095 in
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
const () from /usr/lib64/../lib64/libLLVM.so.3.7
#8  0x00007f0cd60440ec in
llvm::SelectionDAGBuilder::lowerInvokable(llvm::TargetLowering::CallLoweringInfo&,
llvm::MachineBasicBlock*) () from /usr/lib64/../lib64/libLLVM.so.3.7
#9  0x00007f0cd6032cd1 in
llvm::SelectionDAGBuilder::LowerCallTo(llvm::ImmutableCallSite, llvm::SDValue,
bool, llvm::MachineBasicBlock*) () from /usr/lib64/../lib64/libLLVM.so.3.7
#10 0x00007f0cd6024fc0 in llvm::SelectionDAGBuilder::visitCall(llvm::CallInst
const&) () from /usr/lib64/../lib64/libLLVM.so.3.7
#11 0x00007f0cd601c972 in llvm::SelectionDAGBuilder::visit(llvm::Instruction
const&) () from /usr/lib64/../lib64/libLLVM.so.3.7
#12 0x00007f0cd605aa68 in
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) () from
/usr/lib64/../lib64/libLLVM.so.3.7
#13 0x00007f0cd605a9a2 in
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from
/usr/lib64/../lib64/libLLVM.so.3.7
#14 0x00007f0cd60594f4 in
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from
/usr/lib64/../lib64/libLLVM.so.3.7
#15 0x00007f0cd5e15173 in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from
/usr/lib64/../lib64/libLLVM.so.3.7
#16 0x00007f0cd5d26a0b in llvm::FPPassManager::runOnFunction(llvm::Function&)
() from /usr/lib64/../lib64/libLLVM.so.3.7
#17 0x00007f0cd5d26beb in llvm::FPPassManager::runOnModule(llvm::Module&) ()
from /usr/lib64/../lib64/libLLVM.so.3.7
#18 0x00007f0cd5d26ffb in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
from /usr/lib64/../lib64/libLLVM.so.3.7
#19 0x00007f0cd66048d2 in ?? () from /usr/lib64/../lib64/libLLVM.so.3.7
#20 0x00007f0cd66049a8 in LLVMTargetMachineEmitToMemoryBuffer () from
/usr/lib64/../lib64/libLLVM.so.3.7
#21 0x00007f0cde424cbc in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#22 0x00007f0cde3997ba in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#23 0x00007f0cde39a484 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#24 0x00007f0cde3a5c05 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#25 0x00007f0cde3a6e9c in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#26 0x00007f0cde3a2212 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#27 0x00007f0cde2912f1 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#28 0x00007f0cde219656 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#29 0x00007f0cde0d7d96 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#30 0x00007f0cde0a1324 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#31 0x00007f0cde0a1544 in ?? () from
/usr/lib64/xorg/modules/dri/radeonsi_dri.so
#32 0x00000000018b6e31 in ?? ()
#33 0x0000000001ee8f8a in ?? ()
#34 0x0000000001265a67 in ?? ()
#35 0x0000000001265f72 in ?? ()
#36 0x00000000012662df in ?? ()
#37 0x000000000126a765 in ?? ()
#38 0x0000000000898628 in ?? ()
#39 0x00000000008b7462 in ?? ()
#40 0x0000000000800b72 in ?? ()
#41 0x0000000000efc730 in ?? ()
#42 0x00000000007d2615 in ?? ()
#43 0x00000000004152ee in ?? ()
#44 0x00007f0ce2654870 in __libc_start_main () from /lib64/libc.so.6
#45 0x0000000000435751 in ?? ()
#46 0x00007ffff1bc9748 in ?? ()
#47 0x000000000000001c in ?? ()
#48 0x0000000000000001 in ?? ()
#49 0x00007ffff1bcafe9 in ?? ()
#50 0x0000000000000000 in ?? ()


i have the core dump and the apitrace (but replay the trace don't generate any
problem other than the wrong window output)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 6873 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 651 bytes --]

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

Michel Dänzer <michel@daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Michel Dänzer <michel@daenzer.net> ---
That's because the fix isn't in 11.1.0-rc2. I've now nominated the fix for
backporting to the 11.1 branch, so it should be in the next release candidate.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2385 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel