[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 Eric Gallager changed: What|Removed |Added Target|netbsd, VxWorks, SymbianOS, |netbsd, SymbianOS, LynxOS, |LynxOS, QNX, TPF|QNX, TPF --- Comment #42 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #40) > The definitions have been added for VxWorks at some point. (In reply to hain...@adacore.com from comment #41) > > On 2 Jan 2019, at 23:33, joseph at codesourcery dot com > > wrote: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 > > > > --- Comment #40 from joseph at codesourcery dot com > dot com> --- > > The definitions have been added for VxWorks at some point. > > Yes, https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00761.html > I think. OK, removing it from the list of targets then
[Bug target/88839] [SVE] Poor implementation of blend-like permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88839 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Fix committed to sve-acle-branch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2cd1f397ed5a155e74719977823b28777caa8312 Thanks, Prathamesh
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #42 from Segher Boessenkool --- The "movk" failures... This is from insv_1.c: Trying 7, 6 -> 8: 7: r95:DI=0x1d6b 6: r93:DI=r97:DI&0x REG_DEAD r97:DI 8: r94:DI=r93:DI|r95:DI REG_DEAD r95:DI REG_DEAD r93:DI REG_EQUAL r93:DI|0x1d6b Failed to match this instruction: (set (reg:DI 94) (ior:DI (and:DI (reg:DI 97) (const_int -281470681743361 [0x])) (const_int 32345398706176 [0x1d6b]))) Successfully matched this instruction: (set (reg:DI 95) (and:DI (reg:DI 97) (const_int -281470681743361 [0x]))) Failed to match this instruction: (set (reg:DI 94) (ior:DI (reg:DI 95) (const_int 32345398706176 [0x1d6b]))) It should have matched what it originally cam up with, afaics? This is exactly what movk does? (Don't rely on the input and output regs to agree, like with insv; that only happens by chance. Instead, use separate operands, with "0" constraint, etc.)
[Bug c++/89997] New: Garbled expression in error message with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997 Bug ID: 89997 Summary: Garbled expression in error message with -fconcepts Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redbeard0531 at gmail dot com Target Milestone: --- Usually -fconcepts delivers excellent error messages, but this one is pretty bad. It looks like this goes back to 6.2, when it first started to show the expression. https://godbolt.org/z/m9DlOZ struct Y; struct X { Y operator<< (const char*); }; struct Y { X operator<< (void*); }; template void check() requires requires (X x, T val) { x << "hello" << val; } {} void test() { check(); // no error check(); // mangled error } - : In function 'void test()': :16:16: error: cannot call function 'void check() requires (> [with T = int]' 16 | check(); // mangled error |^ :12:6: note: constraints not satisfied 12 | void check() requires requires (X x, T val) { x << "hello" << val; } {} | ^ :12:6: note: with 'X x' :12:6: note: with 'int val' :12:6: note: the required expression '("hello"->x.X::operator<<() << val)' would be ill-formed What is that expression? How did it end up applying -> to a string literal!?
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 --- Comment #15 from Thomas Koenig --- Author: tkoenig Date: Sat Apr 6 22:10:28 2019 New Revision: 270184 URL: https://gcc.gnu.org/viewcvs?rev=270184&root=gcc&view=rev Log: 2019-04-06 Thomas Koenig PR fortran/87352 * gfortran.h (gfc_component): Add finalized field. * class.c (finalize_component): If the component is already finalized, return early. Set component->finalized on exit. 2019-04-06 Thomas Koenig PR fortran/87352 * gfortran.dg/finalize_28.f90: Adjust count of __builtin_free. * gfortran.dg/finalize_33.f90: Likewise. * gfortran.dg/finalize_34.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/finalize_34.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/finalize_28.f90 trunk/gcc/testsuite/gfortran.dg/finalize_33.f90
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Marc Glisse changed: What|Removed |Added Summary|[8/9 Regression] Larger |[8 Regression] Larger code |code generated from GMP |generated from GMP template |template meta-programming |meta-programming --- Comment #11 from Marc Glisse --- Seems fixed on trunk.
[Bug middle-end/89996] New: [avr] ICE in expand_expr_real_2 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996 Bug ID: 89996 Summary: [avr] ICE in expand_expr_real_2 with -O3 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: gandalf at winds dot org Target Milestone: --- The following fails with GCC 8.2 and 8.3 on AVR. The below output is from 8.3: # avr-gcc -v -O3 -mmcu=atmega1284p -c test2.c -o test2.o Using built-in specs. Reading specs from /usr/local/avr/lib/gcc/avr/8.3.0/device-specs/specs-atmega1284p COLLECT_GCC=avr-gcc Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-bootstrap --disable-libssp Thread model: single gcc version 8.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-O3' '-c' '-o' 'test2.o' '-specs=device-specs/specs-atmega1284p' '-mmcu=avr51' /usr/local/avr/libexec/gcc/avr/8.3.0/cc1 -quiet -v -imultilib avr51 -D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p test2.c -mn-flash=2 -mno-skip-bug -quiet -dumpbase test2.c -mmcu=avr51 -auxbase-strip test2.o -O3 -version -o /tmp/ccYds885.s GNU C17 (GCC) version 8.3.0 (avr) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/8.3.0/../../../../avr/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/local/avr/lib/gcc/avr/8.3.0/include /usr/local/avr/lib/gcc/avr/8.3.0/include-fixed /usr/local/avr/lib/gcc/avr/8.3.0/../../../../avr/include End of search list. GNU C17 (GCC) version 8.3.0 (avr) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e17ca263eb8b0996b4ab7dcf63f27ece during RTL pass: expand test2.c: In function 'send_document.isra.0.constprop': test2.c:33:11: internal compiler error: in expand_expr_real_2, at expr.c:8573 0x51269b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/expr.c:8573 0x70e9a0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9968 0x71c001 expand_expr ../../gcc/expr.h:280 0x71c001 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/expr.c:8575 0x70e9a0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9968 0x6195f1 expand_normal ../../gcc/expr.h:286 0x6195f1 precompute_register_parameters ../../gcc/calls.c:989 0x6195f1 expand_call(tree_node*, rtx_def*, int) ../../gcc/calls.c:4127 0x70e2e6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:11050 0x71734b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/expr.c:5651 0x718189 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5419 0x718189 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:4954 0x626e38 expand_call_stmt ../../gcc/cfgexpand.c:2702 0x626e38 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3638 0x626e38 expand_gimple_stmt ../../gcc/cfgexpand.c:3804 0x628c4f expand_gimple_basic_block ../../gcc/cfgexpand.c:5833 0x62dcc6 execute ../../gcc/cfgexpand.c:6439 Please submit a full bug report. Code to reproduce: extern char *strrchr(const char *, int) __attribute__((__pure__)); extern int strcasecmp_P(const char *, const char *) __attribute__((__pure__)); static const struct { char ext[5]; const char __flash *desc; _Bool subst; } __flash mime_types[]={ {"txt", ((const char __flash []){("text/plain; charset=utf-8")}), 1}, {"html", ((const char __flash []){("text/html; charset=utf-8")}), 1}, {"htm", ((const char __flash []){("text/html; charset=utf-8")}), 1}, }; struct http { char uri[128]; _Bool sendfile_subst; }; typedef struct { unsigned char user[sizeof(struct http)]; } DESC; static void send_document(DESC *d, short err, const char __flash *err_string, const char *file, _Bool conn_close) { struct http *hd=(void *)d->user; const char *ext; unsigned char i; _Bool subst=0; if((ext=strrchr(file, '.'))) { for(i=0;i < (int)(sizeof(mime_types)/sizeof(mime_types[0]));i++) if(!strcasecmp_P(ext, mime_types[i].ext)) { subst=mime_types[i].subst; break; } } hd->sendfile_subst=subst; } static void http_do_uri_request(DESC *d) { struct http *hd=(void *)d->user; char *uri=hd->uri; if(*uri != '/') { send_document(d, 400, ({ static const c
[Bug fortran/57262] Optimize bound intrinsics with dim=var for rank one arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57262 --- Comment #4 from Dominique d'Humieres --- > Not convinced, but let me move it to NEW. More than three years later I am still not convince that such nano-optimisation has any interest. What about closing this PR as WONTFIX.
[Bug c++/89995] New: Misleading error message 'this' was not captured for this lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89995 Bug ID: 89995 Summary: Misleading error message 'this' was not captured for this lambda function Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gabriel.aubut-lussier at outlook dot com Target Milestone: --- The error message given when 'this' cannot be captured is misleading in the sense that it points the user to the lambda that fails to capture 'this' rather than raise questions about why it fails to do so. The icc compiler does the best job of giving context with this error. MSVC also displays a bit more information. Clang has the worst offender. GCC could use a bit of improvement. Aiming for an error message that is closer to icc seems like the ideal solution. The error message given by icc is the following: error: this enclosing-function local variable cannot be referenced in this lambda body because an enclosing lambda does not allow implicit captures Godbolt : https://gcc.godbolt.org/z/rmefHT Sample code for the issue: struct S { void f() { []() { [this]() { }(); }(); } }; int main() { S s; s.f(); }
[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #20 from Dominique d'Humieres --- Updated timings % gfc6 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report ... combiner: 81.12 (55%) usr 1.17 (41%) sys 82.31 (54%) wall 2700699 kB (60%) ggc ... TOTAL : 148.83 2.87 151.88 4503753 kB % gfc7 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report ... combiner: 153.49 (67%) usr 1.64 (44%) sys 155.24 (67%) wall 2700699 kB (60%) ggc ... TOTAL : 228.22 3.77 232.32 4508399 kB % gfc8 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report ... combiner : 427.57 ( 85%) 2.17 ( 53%) 430.01 ( 84%) 2700709 kB ( 60%) ... TOTAL : 505.59 4.06510.13 4499127 kB % gfcp -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report ... combiner : 426.78 ( 85%) 1.55 ( 47%) 428.43 ( 85%) 2700713 kB ( 60%) ... TOTAL : 502.36 3.31505.81 4501068 kB
[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 --- Comment #5 from Dominique d'Humieres --- The patch in comment 4 does not bootstrap: ../../work/gcc/fortran/module.c: In function 'void gfc_use_module(gfc_use_list*)': ../../work/gcc/fortran/module.c:7145:8: error: suggest explicit braces to avoid ambiguous 'else' [-Werror=dangling-else] 7145 | if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE) |^ cc1plus: all warnings being treated as errors This one does --- ../_clean/gcc/fortran/module.c 2019-03-21 20:46:46.0 +0100 +++ gcc/fortran/module.c2019-04-06 16:39:02.0 +0200 @@ -7144,8 +7144,12 @@ gfc_use_module (gfc_use_list *module) for (p = gfc_state_stack; p; p = p->previous) if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE) && strcmp (p->sym->name, module_name) == 0) - gfc_fatal_error ("Cannot USE the same %smodule we're building", - p->state == COMP_SUBMODULE ? "sub" : ""); + { + if (p->state == COMP_SUBMODULE) + gfc_fatal_error ("Cannot USE a submodule that is currently built"); + else + gfc_fatal_error ("Cannot USE a module that is currently built"); + } init_pi_tree (); init_true_name_tree ();
[Bug fortran/89981] [8 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 Thomas Koenig changed: What|Removed |Added Summary|[8/9 Regression] gfortran |[8 Regression] gfortran |-pedantic rejects code in |-pedantic rejects code in |8.3.1 that is accepted with |8.3.1 that is accepted with |8.3.0 |8.3.0 --- Comment #5 from Thomas Koenig --- Fixed on trunk so far.
[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Sat Apr 6 14:16:01 2019 New Revision: 270182 URL: https://gcc.gnu.org/viewcvs?rev=270182&root=gcc&view=rev Log: 2019-04-06 Thomas Koenig PR fortran/89981 * resolve.c (resolve_global_procedure): If the global symbol is an ENTRY, also look up its name among the entries. 2019-04-06 Thomas Koenig PR fortran/89981 * gfortran.dg/entry_22.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985 --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > since the issue of calls to inform being done without checking the return > value of warning[_at] first seems to keep coming up, I almost wonder if it's > worth adding __attribute__((unused_result)) to warning[_at]... er __attribute__((warn_unused_result)) I mean
[Bug c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- since the issue of calls to inform being done without checking the return value of warning[_at] first seems to keep coming up, I almost wonder if it's worth adding __attribute__((unused_result)) to warning[_at]...
[Bug fortran/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING CC||janus at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- > What is allocate supposed to do if the array and the mold are not > conformable? No answer after more than six years!-(Shall I close the PR as INVALID to get one?).
[Bug fortran/82055] segfault compiling F2003 functionality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82055 Dominique d'Humieres changed: What|Removed |Added Summary|segfault compiling F2003|segfault compiling F2003 |functionality: 4.9.3, |functionality |5.3.0 and 6.3.0 | --- Comment #5 from Dominique d'Humieres --- Compiling the test with my recent instrumented compiler (9.0) gives ../../work/gcc/tree.h:3289:28: runtime error: member access within null pointer of type 'union tree_node' thus I have removed the references to unsupported versions.
[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dominiq at lps dot ens.fr --- Comment #4 from Dominique d'Humieres --- Updated patch I am planning to commit --- ../_clean/gcc/fortran/module.c 2019-03-21 20:46:46.0 +0100 +++ gcc/fortran/module.c2019-04-06 12:40:17.0 +0200 @@ -7144,8 +7144,10 @@ gfc_use_module (gfc_use_list *module) for (p = gfc_state_stack; p; p = p->previous) if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE) && strcmp (p->sym->name, module_name) == 0) - gfc_fatal_error ("Cannot USE the same %smodule we're building", - p->state == COMP_SUBMODULE ? "sub" : ""); + if (p->state == COMP_SUBMODULE) +gfc_fatal_error ("Cannot USE a submodule that is currently built"); + else +gfc_fatal_error ("Cannot USE a module that is currently built"); init_pi_tree (); init_true_name_tree (); AFAICT the errors are not covered by the test suite.
[Bug c++/89994] [8 Regression] ICE (segfault) in compare_ics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89994 Matthias Klose changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||7.4.1, 9.0 Known to fail||8.3.1 --- Comment #1 from Matthias Klose --- works on the gcc-7 branch and the trunk, ICEs on the gcc-8-branch.
[Bug c++/89994] New: [8 Regression] ICE (segfault) in compare_ics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89994 Bug ID: 89994 Summary: [8 Regression] ICE (segfault) in compare_ics Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- $ cat test.ii template class a; namespace b { template class b; template struct c; template struct c> { using e = typename c>>::e; }; template struct c<0, b> { using e = b; }; template class baseclass, int g, int h, typename i, typename... j> class b, j...> { b(long); b(const long (&)[]); }; } // namespace b template using blaspp = typename b::c>::e; blaspp<1> k({4}) $ g++ -c test.ii test.ii:23:16: internal compiler error: Segmentation fault blaspp<1> k({4}) ^ 0x8a0698 crash_signal ../../src/gcc/toplev.c:325 0x5aa51e compare_ics ../../src/gcc/cp/call.c:9684 0xe8cbe1 joust ../../src/gcc/cp/call.c:10124 0xe8a7f6 tourney ../../src/gcc/cp/call.c:10526 0xe8a7f6 build_new_method_call_1 ../../src/gcc/cp/call.c:9295 0xe8a7f6 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../src/gcc/cp/call.c:9462 0xe8a7f6 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int) ../../src/gcc/cp/call.c:8989 0xede19b expand_default_init ../../src/gcc/cp/init.c:1906 0xede19b expand_aggr_init_1 ../../src/gcc/cp/init.c:2021 0xede19b build_aggr_init(tree_node*, tree_node*, int, int) ../../src/gcc/cp/init.c:1761 0xec44b8 build_aggr_init_full_exprs ../../src/gcc/cp/decl.c:6292 0xec44b8 check_initializer ../../src/gcc/cp/decl.c:6441 0xec2cbf cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../src/gcc/cp/decl.c:7154 0xf03597 cp_parser_init_declarator ../../src/gcc/cp/parser.c:19819 0xefec29 cp_parser_simple_declaration ../../src/gcc/cp/parser.c:13058 0xefe415 cp_parser_block_declaration ../../src/gcc/cp/parser.c:12877 0xefd737 cp_parser_declaration ../../src/gcc/cp/parser.c:12775 0xefd54a cp_parser_declaration_seq_opt ../../src/gcc/cp/parser.c:12651 0x14ba85b cp_parser_translation_unit ../../src/gcc/cp/parser.c:4563 0x14ba85b c_parse_file() ../../src/gcc/cp/parser.c:39118 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. $ g++-7 -c test.ii test.ii:18:21: error: parameter '' includes reference to array of unknown bound 'const long int []' b(const long (&)[]); ^ test.ii:23: confused by earlier errors, bailing out $ g++-9 -c test.ii test.ii:23:16: error: call of overloaded 'b()' is ambiguous 23 | blaspp<1> k({4}) |^ test.ii:18:3: note: candidate: 'b::b, j ...>::b(const long int (&)[]) [with l = double; long unsigned int f = 1; baseclass = a; int g = 0; int h = 1; i = void; j = {}]' 18 | b(const long (&)[]); | ^ test.ii:17:3: note: candidate: 'b::b, j ...>::b(long int) [with l = double; long unsigned int f = 1; baseclass = a; int g = 0; int h = 1; i = void; j = {}]' 17 | b(long); | ^ test.ii:16:7: note: candidate: 'constexpr b::b >::b(const b::b >&)' 16 | class b, j...> { | ^ test.ii:16:7: note: candidate: 'constexpr b::b >::b(b::b >&&)' test.ii:23:16: error: expected ',' or ';' at end of input 23 | blaspp<1> k({4}) |^