| Summary: | ast.h:648:16: error: union member 'i' has a non-trivial constructor | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | currojerez, pedretti.fabio, plamena.manolova |
| Version: | git | Keywords: | bisected, regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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 > 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 What's going on with this bug? I'm tempted to revert the change soon if it can't be fixed. (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. Should be fixed in master now, closing. (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.
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>