[Bug 97532] Regression: GLB 2.7 segfaults due to bogus linker precision error (259fc505) on dead variable

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 97532
           Summary: Regression: GLB 2.7 segfaults due to bogus linker
                    precision error (259fc505) on dead variable
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: idr at freedesktop.org
          Reporter: eero.t.tamminen at intel.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Following commit breaks all GLBenchmark 2.7 tests:
--------------------------------------------------
commit 259fc505454ea6a67aeacf6cdebf1398d9947759
Author:     Ian Romanick <ian.d.romanick at intel.com>
AuthorDate: Tue May 24 12:04:53 2016 -0700
Commit:     Ian Romanick <ian.d.romanick at intel.com>
CommitDate: Fri Aug 26 15:03:15 2016 -0700

    glsl/linker: Fail linking on ES if uniform precision qualifiers don't match

    When GL_OES_geometry_shader is enabled, this fixes
   
dEQP-GLES31.functional.shaders.linkage.geometry.uniform.rules.type_mismatch_1.

    Signed-off-by: Ian Romanick <ian.d.romanick at intel.com>
    Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu>
    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
--------------------------------------------------

Wit that commit in, GLBenchmark 2.7 segfaults to:
--------------------------------------------------
...
Log: glDiscardFramebufferEXT = 0x7ff44873b0a0
Log: error: declarations for uniform `fragmentColorVP` have mismatching
precision qualifiers

Program received signal SIGSEGV, Segmentation fault.
0x0000000000482cf0 in cFont::Draw(float, float) ()
(gdb) bt
#0  0x0000000000482cf0 in cFont::Draw(float, float) ()
#1  0x000000000043233a in GLB::Application::DrawFont(char const*) ()
#2  0x00000000004336ad in GLB::Application::RenderLoadingScreen() ()
#3  0x000000000042e1ec in main ()
(gdb) disassemble
...
   0x0000000000482cd0 <+240>:   callq  0x42d940 <glUniform3fv at plt>
   0x0000000000482cd5 <+245>:   mov    0xa0(%rbx),%eax
   0x0000000000482cdb <+251>:   mov    0x2ae45e(%rip),%rbp        # 0x731140
   0x0000000000482ce2 <+258>:   mov    0x2ae15f(%rip),%r14        # 0x730e48
   0x0000000000482ce9 <+265>:   mov    0x2ae2a8(%rip),%r13        # 0x730f98
=> 0x0000000000482cf0 <+272>:   movb   $0x1,0x0(%rbp,%rax,2)
   0x0000000000482cf5 <+277>:   mov    0xa4(%rbx),%eax
...
(gdb) info registers 
rax            0xffffffff       4294967295
rbx            0x748188 7635336
rcx            0xb      11
rdx            0x7c5280 8147584
rsi            0x502    1282
rdi            0x7a1268 8000104
rbp            0x734d80 0x734d80
<GLB::OpenGLStateManager::m_desired_enabled_vertex_attrib_arrays>
--------------------------------------------------

With the patch reverted, GLB works fine.

Problem is a vertex/fragment shader pair compiled at GLB startup, which
declares the same (above mentioned) uniform in both shaders.  Vertex shader
uses high precision and fragment shader medium precision with GLES (typical
case).

Vertex shader doesn't use the given uniform, so the error is bogus.  Errors
like this should be handled only after optimizations, not before.

Erroring on dead code is nasty, warning on dead code would be OK in this case,
but in general warnings on dead code are nasty too (e.g. bogus warnings about
array accesses that are guarded by correct array size checks, like in some of
the 4.x GCC versions).

Most of the GLB tests don't use that shader, and T-Rex test uses it only at
startup.  T-Rex in GfxBench 3.1 GLES version doesn't have that shader, so
GfxBench works fine.

Question: Is this linker error relevant/appropriate for GLES v2.x, or should it
be generated only for v3.x?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160829/c7419d81/attachment-0001.html>