[Bug 99608] [BISECTED,REGRESSION] dEQP-GLES2.functional.shaders.preprocessor.definitions.undefine_invalid_*

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jan 31 00:15:13 UTC 2017


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

            Bug ID: 99608
           Summary: [BISECTED,REGRESSION]
                    dEQP-GLES2.functional.shaders.preprocessor.definitions
                    .undefine_invalid_*
           Product: Mesa
           Version: 17.0
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: intel-3d-bugs at lists.freedesktop.org
          Reporter: chadversary at chromium.org
        QA Contact: intel-3d-bugs at lists.freedesktop.org

The following dEQP tests fail on Mesa 17.0:

   
dEQP-GLES2.functional.shaders.preprocessor.definitions.undefine_invalid_object_1_fragment
   
dEQP-GLES2.functional.shaders.preprocessor.definitions.undefine_invalid_object_1_vertex
   
dEQP-GLES2.functional.shaders.preprocessor.definitions.undefine_invalid_object_2_fragment
   
dEQP-GLES2.functional.shaders.preprocessor.definitions.undefine_invalid_object_2_vertex

They passed on older Mesa. Specifically, they pass on the Mesa used by ARC++.

Android CTS 7.1 requires that these tests pass. However, the tests may be
incorrect. Google will eventually need to update ARC++ Mesa, but these failures
will prevent us.

Ian, how do you want to solve this? The bisected commit is yours. Should...
    a) Should the fix go upstream, despite the dubiousness of the test?
    b) Should a bug be filed against dEQP?
    c) Should Google carry the patch out-of-tree, because you strongly disagree
with it?

Here is the oneline fix:

    diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
b/src/compiler/glsl/glcpp/glcpp-parse.y
    index 17c6b9d053..389870462a 100644
    --- a/src/compiler/glsl/glcpp/glcpp-parse.y
    +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
    @@ -318,7 +318,6 @@ control_line_success:
                      * 3.00 shaders.
                      */
                    if (parser->is_gles &&
    -                    parser->version >= 300 &&
                         (strcmp("__LINE__", $3) == 0
                          || strcmp("__FILE__", $3) == 0
                          || strcmp("__VERSION__", $3) == 0


The "guilty" commit is:

    commit 50b49d242d702e4728329cc59f87d929963e7c53
    Author: Ian Romanick <ian.d.romanick at intel.com>
    Date:   Tue Aug 9 14:32:24 2016 -0700

        glcpp: Only disallow #undef of pre-defined macros on GLSL ES >= 3.00
shaders

        Section 3.4 (Preprocessor) of the GLSL ES 3.00 spec says:

           It is an error to undefine or to redefine a built-in (pre-defined)
           macro name.

        The GLSL ES 1.00 spec does not contain this text.

        Section 3.3 (Preprocessor) of the GLSL 1.30 spec says:

           #define and #undef functionality are defined as is standard for C++
           preprocessors for macro definitions both with and without macro
           parameters.

        At least as far as I can tell GCC allow '#undef __FILE__'. 
Furthermore,
        there are desktop OpenGL conformance tests that expect '#undef
        __VERSION__' and '#undef GL_core_profile' to work.

        Fixes:

            GL45-CTS.shaders.preprocessor.definitions.undefine_version_vertex
            GL45-CTS.shaders.preprocessor.definitions.undefine_version_fragment
           
GL45-CTS.shaders.preprocessor.definitions.undefine_core_profile_vertex
           
GL45-CTS.shaders.preprocessor.definitions.undefine_core_profile_fragment

        Signed-off-by: Ian Romanick <ian.d.romanick at intel.com>
        Reviewed-by: Timothy Arceri <timothy.arceri at collabora.com>
        Cc: mesa-stable at lists.freedesktop.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
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/20170131/e52fe794/attachment.html>


More information about the intel-3d-bugs mailing list