Bug 105238 - ast.h:648:16: error: union member 'i' has a non-trivial constructor
Summary: ast.h:648:16: error: union member 'i' has a non-trivial constructor
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2018-02-25 09:02 UTC by Vinson Lee
Modified: 2018-02-27 21:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Vinson Lee 2018-02-25 09:02:23 UTC
In file included from ./glsl/glsl_lexer.ll:27:
../../src/compiler/glsl/ast.h:648:16: error: union member 'i' has a non-trivial constructor
      bitset_t i;
               ^

commit ba79a90fb52e1e81fbfb38113e85a56b13497c50
Author: Francisco Jerez <currojerez@riseup.net>
Date:   Mon Feb 12 14:18:15 2018 -0800

    glsl: Switch ast_type_qualifier to a 128-bit bitset.
    
    This should end the drought of bits in the ast_type_qualifier object.
    The bitset_t type works pretty much as a drop-in replacement for the
    current uint64_t bitset.
    
    The only catch is that the bitset_t type as defined in the previous
    commit doesn't have a trivial constructor (because it has a
    user-defined constructor), so it cannot be used as union member
    without providing a user-defined constructor for the union (which
    causes it in turn to be non-trivially constructible).  This annoyance
    could be easily addressed in C++11 by declaring the default
    constructor of bitset_t to be the implicitly defined one -- IMO one
    more reason to drop support for GCC 4.2-4.3.
    
    The other minor change was required because glsl_parser_extras.cpp was
    hard-coding the type of bitset temporaries as uint64_t, which (unlike
    would have been the case if the uint64_t had been replaced with
    e.g. an __int128) would otherwise have caused a build failure, because
    the boolean conversion operator of bitset_t is marked explicit (if
    C++11 is available), so the bitset won't be silently truncated down to
    1 bit in order to use it to initialize the uint64_t temporaries
    (yikes).
    
    Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
Comment 1 Fabio Pedretti 2018-02-26 09:39:44 UTC
I get a slightly different error, Ubuntu 16.04, newer Ubuntu compile fine.

Full build log:
https://launchpadlibrarian.net/358638969/buildlog_ubuntu-xenial-amd64.mesa_18.1~git1802260730.0cc5be~oibaf~x_BUILDING.txt.gz

Error:
In file included from ../../../../src/compiler/glsl/glsl_lexer.ll:27:0:
../../../../src/compiler/glsl/ast.h:648:16: error: member ‘ast_type_qualifier::bitset_t ast_type_qualifier::flags::i’ with constructor not allowed in union
       bitset_t i;
                ^
../../../../src/compiler/glsl/ast.h:648:16: note: unrestricted unions only available with -std=c++11 or -std=gnu++11
In file included from ../../../../src/compiler/glsl/glsl_lexer.ll:29:0:
../../../../src/compiler/glsl/glsl_parser.yy:106:30: error: member ‘ast_type_qualifier YYSTYPE::type_qualifier’ with constructor not allowed in union
    struct ast_type_qualifier type_qualifier;
                              ^
glsl/glsl_lexer.cpp: In function ‘int yy_get_next_buffer(yyscan_t)’:
glsl/glsl_lexer.cpp:3491:47: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  if ((int) (yyg->yy_n_chars + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
                                               ^
Makefile:2489: recipe for target 'glsl/glsl_lexer.lo' failed
Comment 2 Gert Wollny 2018-02-26 09:54:39 UTC
> I get a slightly different error, Ubuntu 16.04, newer Ubuntu compile fine.

Newer Ubuntus use >= gcc-6, and there compiler -std=c++14 is the default, hence the error is alleviated because: 

> note: unrestricted unions only available with -std=c++11 or -std=gnu++11
Comment 3 Brian Paul 2018-02-27 19:47:14 UTC
What's going on with this bug?  I'm tempted to revert the change soon if it can't be fixed.
Comment 4 Francisco Jerez 2018-02-27 19:56:50 UTC
(In reply to Brian Paul from comment #3)
> What's going on with this bug?  I'm tempted to revert the change soon if it
> can't be fixed.

It can be fixed, a fix has been on the ML since before this bug was filed, I just got an R-b for it now.
Comment 5 Francisco Jerez 2018-02-27 21:03:47 UTC
Should be fixed in master now, closing.
Comment 6 Brian Paul 2018-02-27 21:27:28 UTC
(In reply to Francisco Jerez from comment #5)
> Should be fixed in master now, closing.

Looks good here.  Thanks!


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.