Bug 105740 - glsl_types.cpp(524): error: a dynamically-initialized local static variable is not allowed inside of a statement expression
Summary: glsl_types.cpp(524): error: a dynamically-initialized local static variable i...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2018-03-26 07:38 UTC by Vinson Lee
Modified: 2018-04-13 10:51 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Vinson Lee 2018-03-26 07:38:35 UTC 
Intel C++ Compiler build error

glsl_types.cpp(524): error: a dynamically-initialized local static variable is not allowed inside of a statement expression
     return VECN(components, float, vec);
            ^

commit f407edf3407396379e16b0be74b8d3b85d2ad7f0
Author: Rob Clark <robdclark@gmail.com>
Date:   Mon Mar 12 14:54:56 2018 -0400

    glsl_types: refactor/prep for vec8/vec16
    
    Refactor things so there isn't so much typing involved to add new
    things.
    
    Also drops a pointless conditional (out of bounds rows or columns
    already returns error_type in all paths.. might as well drop it
    rather than make the check more convoluted in the next patch by
    adding the vec8/vec16 case).
    
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Comment 1 Roland Scheidegger 2018-03-26 14:23:29 UTC 
It's not just intel c++, appveyor also complained.
Comment 2 Timothy Arceri 2018-04-13 10:51:44 UTC 
Fixed by:

commit 1e0a06000bae17e1791f55127e7527946e9b6793
Author: Rob Clark <robdclark@gmail.com>
Date:   Mon Mar 26 18:45:07 2018 -0400

    glsl_types: fix build break with intel/msvc compiler
    
    The VECN() macro was taking advantage of a GCC specific feature that is
    not available on lesser compilers, mostly for the purposes of avoiding a
    macro that encoded a return statement.
    
    But as suggested by Ian, we could just have the macro produce the entire
    method body and avoid the need for this.  So let's do that instead.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
    Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
    Cc: Emil Velikov <emil.velikov@collabora.com>
    Cc: Timothy Arceri <tarceri@itsqueeze.com>
    Cc: Roland Scheidegger <sroland@vmware.com>
    Cc: Ian Romanick <idr@freedesktop.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

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.