[Bug preprocessor/91412] Unexpectedly correct raw string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91412 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #1 from Tom Honermann --- My understanding is that the usual rationale for removal of trailing whitespace is to consider it part of a newline sequence; similar to considering as a single newline. Using that rationale, it seems appropriate that the spaces be retained as part of translation phase 2 reversion; just as it would presumably be desirable to preserve a sequence through such reversion.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 --- Comment #3 from Tom Honermann --- A patch for this issue has been submitted: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00150.html
[Bug driver/91130] [9 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #46 from Tom Honermann --- Fixed for 9.3 and 10.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 Tom Honermann changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.1 Resolution|--- |FIXED Target Milestone|--- |9.3 Known to fail||9.1.0, 9.2.0 --- Comment #7 from Tom Honermann --- Fixed for 9.3 and 10.
[Bug c++/71125] [concepts] Spurious 'invalid reference to function concept error' issued when overloads are not all declared with the concept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125 --- Comment #5 from Tom Honermann --- (In reply to Andrew Sutton from comment #3) > Function concepts have some parsing issues related to TS-style terse > notation, overloading and variadic templates. In particular, there are > places where writing C forms a (possibly) syntactically valid placeholder > C as part of a functional cast expression, which leads to the error > you're seeing: you're incompletely instantiating a template-id that resolved > to the template with two parameters. I was going to argue that that explanation didn't explain why the reported diagnostic doesn't occur when the order of the overload declarations are swapped. However, I did a quick test and found that, indeed, the diagnostic is not issued for the swapped case in gcc 6.1.0, but is in gcc 6.3, 7.1, and later. It seems the lack of a diagnostic in that case was some other issue that has since been fixed. (In reply to Jonathan Wakely from comment #4) > I think the "conflicts with a previous declaration" diagnostic is > reasonable. Maybe "redeclared as a different kind of symbol" would also work. I agree the diagnostics for the C++20 case are appropriate. I don't have an opinion on whether it is worth trying to improve them further. > I'll recategorise it as a diagnostic enhancement and confirm it, but I think > closing it would also be fine. As the original reported, I'm ok with this being closed since the original issue isn't relevant for C++20 concepts. I don't recall the situation that caused me to trip over this issue in the first place. I suspect I was just playing around with the interaction between constexpr and concept functions.
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #2 from Tom Honermann --- I think my preferred fix to this is to introduce new length modifiers for the "%s" conversion specifier for all of char8_t, char16_t, and char32_t.
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #4 from Tom Honermann ---
(In reply to Florian Weimer from comment #3)
> But the precedent with wchar_t is that the type of the format string
> determines the type of the %s arguments. I'm not sure if that's a good
> precedent, but it's what we have today.
That matches Microsoft's documented behavior
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2019),
but it runs contrary to the C standard (C11 7.29.2.1) and glibc behavior.
To be clear, the position I'm suggesting is that we add support for something
like these:
printf("%U8s", u8"text");
printf("%U8c", u8'x');
wprintf(L"%U8s", u8"text");
wprintf(L"%U8c", u8'x');
printf("%U16s", u"text");
printf("%U16c", u'x');
wprintf(L"%U16s", u"text");
wprintf(L"%U16c", u'x');
printf("%U32s", U"text");
printf("%U32c", U'x');
wprintf(L"%U32s", U"text");
wprintf(L"%U32c", U'x');
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #6 from Tom Honermann --- (In reply to jos...@codesourcery.com from comment #5) > We (GCC) don't control printf; I know, by "we" I meant the C and C++ standards community. > the format checking should match what the > actual libc supports. Agreed.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 --- Comment #2 from Tom Honermann --- I confirmed that Jeff's patch, applied to gcc 9.1.0, suffices to address both Hana's test case and the code in the "Emulate C++17 u8 literals" section of P1423R2 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r2.html#emulate) if the declaration of operator <=> is commented out (since gcc doesn't yet support operator <=>).
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1 from Tom Honermann ---
I'm also experiencing this; gcc r234493.
$ cat t.cpp
template
constexpr bool b = false;
template
constexpr bool b = true;
int main() {
b;
b;
}
$ g++ -std=c++14 t.cpp -o t
/tmp/ccYIejpd.s: Assembler messages:
/tmp/ccYIejpd.s:27: Error: symbol `_ZL1b' is already defined
$ gcc --version
gcc (GCC) 6.0.0 20160327 (experimental)
...
[Bug c++/70095] [C++14] Link error on partially specialized variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70095
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #2 from Tom Honermann ---
The change in comment 1 introduced a regression. The following test passes
with r234230, but fails with r234231:
$ cat t.cpp
template
constexpr bool b = false;
template
constexpr bool b = true;
int main() {
b;
b;
}
$ g++ -std=c++14 t.cpp -o t
/tmp/ccJTAQId.s: Assembler messages:
/tmp/ccJTAQId.s:27: Error: symbol `_ZL1b' is already defined
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #2 from Tom Honermann --- (In reply to Tom Honermann from comment #1) Actually, the test case in comment 1 seems to be a different issue; its failure is a regression introduced in r234231 via bug 70095. As of r234231 (and up through at least r234502), the test case in comment 0 triggers an ICE. $ g++ -std=c++14 t.cpp -o t t.cpp:9:31: error: Two symbols with same comdat_group are not linked by the same_comdat_group list. auto&& b = foo>; ^ foo/3 (A foo) @0x7f6c0f987000 Type: variable definition analyzed Visibility: public weak comdat comdat_group:foo one_only previous sharing asm name: 2 References: Referring: b/1 (addr)_Z41__static_initialization_and_destruction_0ii/5 (addr) Availability: not-ready Varpool flags: foo/2 (A foo) @0x7f6c0f97cf80 Type: variable definition analyzed Visibility: public weak comdat comdat_group:foo one_only next sharing asm name: 3 References: Referring: a/0 (addr)_Z41__static_initialization_and_destruction_0ii/5 (addr) Availability: not-ready Varpool flags: t.cpp:9:31: internal compiler error: symtab_node::verify failed 0x928ee1 symtab_node::verify_symtab_nodes() ../../gcc-trunk/gcc/symtab.c:1219 0x93ba14 symtab_node::checking_verify_symtab_nodes() ../../gcc-trunk/gcc/cgraph.h:602 0x93ba14 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2380 0x93df87 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2536 0x93df87 symbol_table::finalize_compilation_unit() ../../gcc-trunk/gcc/cgraphunit.c:2562
[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #2 from Tom Honermann --- This looks to be a duplicate of bug 70095.
[Bug c++/70037] [concepts] comdat group error and an ICE with a conceptified tuple implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #2 from Tom Honermann --- This error was also reported in bug 69515 comment 2.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #3 from Tom Honermann --- The error in comment 2 was also reported in bug 69364.
[Bug c++/71125] New: [concepts] Spurious 'invalid reference to function concept error' issued when overloads are not all declared with the concept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125
Bug ID: 71125
Summary: [concepts] Spurious 'invalid reference to function
concept error' issued when overloads are not all
declared with the concept specifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following code is well-formed.
$ cat t.cpp
// This test case demonstrates a spurious reference to function concept error.
// The error is emitted when:
// 1: a constexpr function is declared without the concept specifier, and
// 2: an overload declared with the concept specifier follows, and
// 3: overload resolution of a function invocation in a requires clause of a
//following constrained function declaration selects the first declaration.
template
constexpr bool C1() { return true; }
template
concept bool C1() { return true; }
template
requires C1() // spurious error: invalid reference to function concept
‘template constexpr bool C1()’
void f1() {}
// Removing the unused overload avoids the error:
template
constexpr bool C2() { return true; }
template
requires C2() // Ok.
void f2() {}
// Swapping the order of the declarations avoids the error:
template
concept bool C3() { return true; }
template
constexpr bool C3() { return true; }
template
requires C3() // Ok.
void f3() {}
// Swapping the overload that is resolved avoids the error:
template
constexpr bool C4() { return true; }
template
concept bool C4() { return true; }
template
requires C4() // Ok.
void f4() {}
// Swapping which overload is declared with the concept specifier avoids the
error:
template
concept bool C5() { return true; }
template
constexpr bool C5() { return true; }
template
requires C5() // Ok.
void f5() {}
$ svn info # From my local svn gcc repo.
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -fconcepts -std=c++1z t.cpp
t.cpp:13:12: error: invalid reference to function concept ‘template constexpr bool C1()’
requires C1() // spurious error: invalid reference to function concept
‘template constexpr bool C1()’
^
[Bug c++/71126] New: [concepts] ICE on ill-formed code declaring a variable with a non-type concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71126 Bug ID: 71126 Summary: [concepts] ICE on ill-formed code declaring a variable with a non-type concept Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code triggers an ICE in gcc r236239. $ cat t.cpp template concept bool C = N==1; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp t.cpp:3:7: internal compiler error: tree check: expected tree_vec, have error_mark in tsubst, at cp/pt.c:12954 C c = 1; ^ 0xff7e0c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc-trunk/gcc/tree.c:9753 0x6bd076 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc-trunk/gcc/tree.h:3025 0x6bd076 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-trunk/gcc/cp/pt.c:12954 0x6b1a78 tsubst_copy ../../gcc-trunk/gcc/cp/pt.c:14077 0x6b787a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:17161 0x6b720b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:16176 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x6deb08 lookup_and_finish_template_variable ../../gcc-trunk/gcc/cp/pt.c:8715 0x6b87c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:15991 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x88b694 constraints_satisfied_p(tree_node*, tree_node*) ../../gcc-trunk/gcc/cp/constraint.cc:2146 0x6eaf3a do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context) ../../gcc-trunk/gcc/cp/pt.c:24065 0x67a9bb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc-trunk/gcc/cp/decl.c:6606 0x77e62f cp_parser_init_declarator ../../gcc-trunk/gcc/cp/parser.c:18694 ...
[Bug c++/71127] New: [concepts] ICE on ill-formed code declaring a variable with a template concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71127 Bug ID: 71127 Summary: [concepts] ICE on ill-formed code declaring a variable with a template concept Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code triggers an ICE in gcc r236239. $ cat t.cpp template class T> concept bool C = T::value; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp t.cpp:3:7: internal compiler error: tree check: expected tree_vec, have error_mark in tsubst, at cp/pt.c:12954 C c = 1; ^ 0xff7e0c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc-trunk/gcc/tree.c:9753 0x6bd076 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc-trunk/gcc/tree.h:3025 0x6bd076 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-trunk/gcc/cp/pt.c:12954 0x6b50aa tsubst_qualified_id ../../gcc-trunk/gcc/cp/pt.c:13728 0x6b70a3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:16204 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x6deb08 lookup_and_finish_template_variable ../../gcc-trunk/gcc/cp/pt.c:8715 0x6b87c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:15991 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x88b694 constraints_satisfied_p(tree_node*, tree_node*) ../../gcc-trunk/gcc/cp/constraint.cc:2146 0x6eaf3a do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context) ../../gcc-trunk/gcc/cp/pt.c:24065 0x67a9bb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc-trunk/gcc/cp/decl.c:6606 0x77e62f cp_parser_init_declarator ../../gcc-trunk/gcc/cp/parser.c:18694 0x77ed29 cp_parser_simple_declaration ../../gcc-trunk/gcc/cp/parser.c:12378 ...
[Bug c++/71128] New: [concepts] ICE on ill-formed explicit instantiation of a function concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71128
Bug ID: 71128
Summary: [concepts] ICE on ill-formed explicit instantiation of
a function concept
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an ICE in gcc r236239.
$ cat t.cpp
template
concept bool C() { return true; }
template bool C(); // expected error: attempt to explicitly instantiate
// a function concept.
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:3:22: internal compiler error: in instantiate_decl, at cp/pt.c:21666
template bool C();
^
0x6a8c51 instantiate_decl(tree_node*, int, bool)
../../gcc-trunk/gcc/cp/pt.c:21666
0x77751d cp_parser_explicit_instantiation
../../gcc-trunk/gcc/cp/parser.c:15648
0x788c79 cp_parser_declaration
../../gcc-trunk/gcc/cp/parser.c:12095
0x7874b6 cp_parser_declaration_seq_opt
../../gcc-trunk/gcc/cp/parser.c:12022
0x7877c4 cp_parser_translation_unit
../../gcc-trunk/gcc/cp/parser.c:4324
0x7877c4 c_parse_file()
../../gcc-trunk/gcc/cp/parser.c:37475
0x8e7e42 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
...
[Bug c++/71129] New: [concepts] ICE on ill-formed explicit instantiation of a variable concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71129 Bug ID: 71129 Summary: [concepts] ICE on ill-formed explicit instantiation of a variable concept Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code triggers an ICE in gcc r236239. $ cat t.cpp template concept bool C = true; template bool C; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp t.cpp:3:15: internal compiler error: in instantiate_decl, at cp/pt.c:21666 template bool C; ^~ 0x6a8c51 instantiate_decl(tree_node*, int, bool) ../../gcc-trunk/gcc/cp/pt.c:21666 0x77751d cp_parser_explicit_instantiation ../../gcc-trunk/gcc/cp/parser.c:15648 0x788c79 cp_parser_declaration ../../gcc-trunk/gcc/cp/parser.c:12095 0x7874b6 cp_parser_declaration_seq_opt ../../gcc-trunk/gcc/cp/parser.c:12022 0x7877c4 cp_parser_translation_unit ../../gcc-trunk/gcc/cp/parser.c:4324 0x7877c4 c_parse_file() ../../gcc-trunk/gcc/cp/parser.c:37475 0x8e7e42 c_common_parse_file() ../../gcc-trunk/gcc/c-family/c-opts.c:1064 ...
[Bug c++/71130] New: [concepts] Ill-formed code declaring a variable with a non-type concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71130 Bug ID: 71130 Summary: [concepts] Ill-formed code declaring a variable with a non-type concept not rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code is not rejected as it should be in gcc r236239. This test case is similar to the one that triggers an ICE in bug 71126. $ cat t.cpp template concept bool C = true; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp; echo $? 0
[Bug c++/71131] New: [concepts] Ill-formed code declaring a variable with a template concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71131 Bug ID: 71131 Summary: [concepts] Ill-formed code declaring a variable with a template concept not rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code is not rejected as it should be in gcc r236239. This test case is similar to the one that triggers an ICE in bug 71127. $ cat t.cpp template class T> concept bool C = true; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp; echo $? 0
[Bug c++/71136] New: [concepts] Spurious 'converting overloaded function is ambiguous' error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71136
Bug ID: 71136
Summary: [concepts] Spurious 'converting overloaded function is
ambiguous' error.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following test case is well-formed, but it is rejected by gcc
r236238.
$ cat t.cpp
template
struct is_same {};
template
struct is_same { using type = T; };
// Concept imposes a same-type-as-int constraint.
template
concept bool C = requires { typename is_same::type; };
template
constexpr int f() { return 0; } // #1, unconstrained overload.
template
constexpr int f() { return 1; } // #2, constrained overload.
// Obtaining a function pointer to #1 is ok:
constexpr auto x0 = f;// Ok, overload selects #1
static_assert(x0() == 0); // Ok.
// Invoking #2 is ok:
constexpr auto x1 = f(); // Ok, overload selects #2
static_assert(x1 == 1); // Ok.
// Obtaining a function pointer to #2 fails:
constexpr auto x2 = f; // spurious error: 'converting overloaded
// function is ambiguous'; should select #2.
static_assert(x2() == 1);
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:24:21: error: converting overloaded function ‘f’ to type ‘int (*
const)()’ is ambiguous
constexpr auto x2 = f; // spurious error: 'converting overloaded
^~
t.cpp:11:15: note: candidates are: constexpr int f() [with U = int]
constexpr int f() { return 0; } // #1, unconstrained overload.
^
t.cpp:13:15: note: constexpr int f() [with U = int]
constexpr int f() { return 1; } // #2, constrained overload.
^
t.cpp:26:1: error: non-constant condition for static assertion
static_assert(x2() == 1);
^
[Bug c++/71137] New: [concepts] Spurious 'symbol is already defined' error issued when declaring a constrained non-template function overload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71137
Bug ID: 71137
Summary: [concepts] Spurious 'symbol is already defined' error
issued when declaring a constrained non-template
function overload.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following test case is well-formed; the Concepts TS has similar
examples (§ 13.4p4). However, compiling this code results in a duplicate
definition error in gcc r236238.
$ cat t.cpp
void f() {}
void f() requires true {}
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
/tmp/ccONCRCJ.s: Assembler messages:
/tmp/ccONCRCJ.s:22: Error: symbol `_Z1fv' is already defined
[Bug c++/71138] New: [concepts] ill-formed non-constant expression use in nested requirement produces duplicated diagnostics with poor source locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71138
Bug ID: 71138
Summary: [concepts] ill-formed non-constant expression use in
nested requirement produces duplicated diagnostics
with poor source locations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following test case is ill-formed and gcc r236238 correctly rejects it.
However, duplicate diagnostic are issued and the diagnostics fail to identify
the problematic source code.
The test case contains two instances of constraint satisfaction failures
labeled #1 and #2. The first occurs in a static_assert and produces a single
error message. The second occurs in overload resolution and produces three
duplicate error messages.
None of the diagnostics produce identify the problematic source code annotated
in the test case.
$ cat t.cpp
template
constexpr bool p(T) { return true; }
template
concept bool C = requires(T t) {
requires p(t); // An error should be reported here.
};
static_assert(C); // #1: error: ‘t’ is not a constant expression
template
int f(T) { return 1; }
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:8:15: error: ‘t’ is not a constant expression
static_assert(C); // #1: error: ‘t’ is not a constant expression
^~
t.cpp:12:13: error: ‘t’ is not a constant expression
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
^
t.cpp:12:13: error: ‘t’ is not a constant expression
t.cpp:12:13: error: cannot call function ‘int f(T) [with T = int]’
t.cpp:11:5: note: constraints not satisfied
int f(T) { return 1; }
^
t.cpp:12:13: error: ‘t’ is not a constant expression
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
^
t.cpp:11:5: note: concept ‘C’ was not satisfied
int f(T) { return 1; }
^
[Bug c++/71139] New: [concepts] ill-formed compound-requirement lacking a semicolon not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71139
Bug ID: 71139
Summary: [concepts] ill-formed compound-requirement lacking a
semicolon not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not rejected by gcc r236238. According to the
Concepts TS § 5.1.4.3, the compound-requirement must include a terminating
semicolon.
$ cat a.cpp
template
concept bool C = requires(T t) {
{ +t }
}; // expected error: expected ‘;’ before ‘}’ token
static_assert(C);
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts a.cpp; echo $?
0
[Bug c++/71140] New: [concepts] ill-formed nested-requirement lacking a semicolon not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71140
Bug ID: 71140
Summary: [concepts] ill-formed nested-requirement lacking a
semicolon not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not rejected by gcc r236238. According to the
Concepts TS § 5.1.4.4, the nested-requirement must include a terminating
semicolon.
$ cat a.cpp
template
concept bool C = requires(T t) {
requires true
}; // expected error: expected ‘;’ before ‘}’ token
static_assert(C);
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts a.cpp; echo $?
0
[Bug c++/71141] New: [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141 Bug ID: 71141 Summary: [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following test case is taken from example code in the Concepts TS § 14.1 p9.4. gcc r236238 rejects this code. I presume the code is intended to be well-formed; if not, then the Concepts TS should be updated. $ cat t1.cpp template concept bool C4 = true; template void f5(); $ g++ -c -std=c++1z -fconcepts t1.cpp t1.cpp:2:14: error: variadic constraint introduced without ‘...’ before ‘>’ token template void f5(); ^ The example is accepted if the constrained function is re-written with a requires clause: $ cat t2.cpp template concept bool C4 = true; template requires C4 void f5(); $ g++ -c -std=c++1z -fconcepts t2.cpp; echo $? 0 An error is similarly produced when using a variadic non-type concept: $ cat t3.cpp template concept bool C5 = true; template void f7(); $ g++ -c -std=c++1z -fconcepts t3.cpp t3.cpp:2:14: error: variadic constraint introduced without ‘...’ before ‘>’ token template void f7(); ^
[Bug c++/71141] [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141 --- Comment #1 from Tom Honermann --- If it is decided that this code is well-formed, then I think the declaration of f7() in t3.cpp should be added to the example in the Concepts TS.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #4 from Tom Honermann --- (In reply to Tom Honermann from comment #3) > The error in comment 2 was also reported in bug 69364. I don't know where I got that bug number from. That should have been: The error in comment 2 was also reported in bug 70037.
[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862 --- Comment #4 from Tom Honermann --- (In reply to ryan.burn from comment #3) > It's a different bug. The test case from 70095 compiles fine with the trunk > from 20160428, but the above example won't. The example in bug 70095 comment 2 still fails the same way. That example is known to be a regression caused by the change noted in bug 70095 comment 1 that intended to fix the example in bug 70095 comment 0. That change also affected the behavior of the example in bug 69515 (but didn't fix it). I don't know how related these issues are.
[Bug c++/71221] New: [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
Bug ID: 71221
Summary: [concepts] ICE in tsubst_pack_expansion when expanding
a sizeof... expression in a requires clause of a
member function template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following test case demonstrates an internal compiler error that occurs
with gcc 7.0.0 (r236423) when expanding a sizeof... expression in a requires
clause of a member function template.
$ cat t.cpp
template
struct int_sequence {};
template
struct S {
template
requires sizeof...(Is) == N
int mf1(int_sequence);
void mf2() {
mf1(int_sequence<>{});
}
};
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236427
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236423
Last Changed Date: 2016-05-18 15:15:22 -0400 (Wed, 18 May 2016)
$ g++ --version
g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp: In member function ‘void S::mf2()’:
t.cpp:6:20: internal compiler error: in tsubst_pack_expansion, at cp/pt.c:10967
requires sizeof...(Is) == N
^~~
0x6c758f tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:10967
0x6b190b tsubst_copy
../../gcc-trunk/gcc/cp/pt.c:14131
0x6b525a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:17161
0x6b4beb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:16176
0x6a99ee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889a67 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889a67 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a866 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x88a9bc constraints_satisfied_p(tree_node*)
../../gcc-trunk/gcc/cp/constraint.cc:2133
0x64807c add_function_candidate
../../gcc-trunk/gcc/cp/call.c:2013
0x648d9c add_template_candidate_real
../../gcc-trunk/gcc/cp/call.c:3146
0x649693 add_template_candidate
../../gcc-trunk/gcc/cp/call.c:3188
0x649693 add_candidates
../../gcc-trunk/gcc/cp/call.c:5361
0x649f2f build_new_method_call_1
../../gcc-trunk/gcc/cp/call.c:8313
0x649f2f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-trunk/gcc/cp/call.c:8512
0x7610f2 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6875
0x75ebdc cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7986
0x768db7 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8663
0x7693a3 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8764
0x769c94 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9051
...
[Bug c++/71222] New: [concepts] ill-formed code taking the address of a function concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222
Bug ID: 71222
Summary: [concepts] ill-formed code taking the address of a
function concept not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following code is ill-formed though I was unable to find
normative text in N4553 that explicitly makes it such. The following
non-normative note in § 7.1.7p5 [dcl.spec.concept] suggests the intent for this
code to be ill-formed:
[Note: Return type deduction requires the instantiation of the function
definition, but concept definitions are not instantiated; they are normalized
(14.10.2). — end note]
gcc 7.0.0 (r236423) currently accepts this code, though a link error occurs
when linking an executable due to the reference to the uninstantiated FC
function concept. Note that directly invoking the function concept would
produce no errors since the result is evaluated at compile time; only taking
the address and later attempting to invoke the function is ill-formed.
$ cat t.cpp
template
concept bool FC() { return true; }
int main() {
auto fc = &FC;
fc();
}
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236427
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236423
Last Changed Date: 2016-05-18 15:15:22 -0400 (Wed, 18 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160518 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp; echo $?
0
$ g++ -std=c++1z -fconcepts t.o -o t
t.o: In function `main':
t.cpp:(.text+0xc): undefined reference to `bool FC()'
collect2: error: ld returned 1 exit status
[Bug c++/71221] [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221 --- Comment #1 from Tom Honermann --- (In reply to Tom Honermann from comment #0) > $ g++ --version > g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Oops, I ran the above in the wrong terminal session. The correct gcc version info is: $ g++ --version g++ (GCC) 7.0.0 20160518 (experimental) ...
[Bug other/61896] Wrong documentation for -finput-charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61896
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1 from Tom Honermann ---
Created attachment 38565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38565&action=edit
Source file with ill-formed UTF-8 code unit sequences
Gcc's incorrect documentation regarding the default input character set
continues to be a source of confusion. See the discussion on the C++
std-proposals list at the following link (search for 'locale').
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/Draft$20proposal$20of$20file$20string/std-proposals/tKioR8OUiAw/85NCUmojBwAJ
The current gcc 6.1.0 documentation for -finput-charset can be found here:
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Preprocessor-Options.html#Preprocessor-Options
The relevant text is:
-finput-charset=charset
Set the input character set, used for translation from the character set of
the input file to the source character set used by GCC. If the locale does
not specify, or GCC cannot get this information from the locale, the
default is UTF-8. This can be overridden by either the locale or this
command-line option. Currently the command-line option takes precedence if
there's a conflict. charset can be any encoding supported by the system's
iconv library routine.
The patch proposed in attachment 33179 in comment 0 is an improvement in that
it removes the incorrect references to use of the current locale in determining
the input character set. However, the proposed documentation is still
incorrect, or at least imprecise, with regard to use of UTF-8 as the default
input character set since gcc does not reject (or even emit a warning for)
ill-formed UTF-8 text.
An example follows. The attached test code (attached to prevent mutation of
the contents) contains ill-formed UTF-8 code unit sequences. Compilation with
gcc 6.1.0 (on a Linux system) succeeds despite the ill-formed input.
# To demonstrate that the text is ill-formed:
$ iconv -f utf-8 -t utf-8 t.cpp
#include
int main()
{
printf("narrow string: (well-formed UTF-8)\n");
for (unsigned char c : "£") { // 0xC2 0xA3
printf(" 0x%X\n", (unsigned int)c);
}
printf("narrow string: (ill-formed UTF-8)\n");
for (unsigned char c : "iconv: illegal input sequence at position 261
$ g++ --version
g++ (GCC) 6.1.0
...
$ g++ -Wall -Wextra -pedantic t.cpp -o t; echo $?
0
$ ./t
narrow string: (well-formed UTF-8)
0xC2
0xA3
0x0
narrow string: (ill-formed UTF-8)
0xA3
0x0
narrow string (hex escape):
0xA3
0x0
UTF-8 string: (well-formed UTF-8)
0xC2
0xA3
0x0
UTF-8 string: (ill-formed UTF-8)
0xA3
0x0
UTF-8 string (hex escape):
0xA3
0x0
As shown above, ill-formed code unit sequences are passed through without being
transcoded to the execution character set (I would expect an error or
translation to a replacement character for the ill-formed sequences).
Note that validation is performed if a non-utf-8 execution character set is
specified.
$ g++ -Wall -Wextra -pedantic -fexec-charset=iso8859-1 t.cpp -o t
t.cpp: In function ‘int main()’:
t.cpp:9:28: error: converting to execution character set: Invalid or incomplete
multibyte or wide character
for (unsigned char c : "�") { // 0xA3
^~~
I propose the documentation be updated to reflect this behavior:
-finput-charset=charset
Set the input character set, used for translation from the character set of
the input file to the source character set used by GCC. The default input
character set is UTF-8. charset can be any encoding supported by the
system's iconv library routine. If the input character set matches the
execution character set, then ill-formed code unit sequences are passed
through without validation or translation. Otherwise, ill-formed code unit
sequences will result in an error during transcoding to the execution
character set.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #6 from Tom Honermann --- (In reply to Jason Merrill from comment #5) > PR c++/60095 - partial specialization of variable templates I believe this was intended to refer to PR c++/70095.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #27 from Tom Honermann ---
We got bit by this warning recently. We compile with -Werror and, without an
option to suppress warnings in the following code, gcc rejects it. We think
this code should be accepted without a warning given the constant expressions
involved.
Clang does not issue a warning for this code. However, if an assignment to the
bit-field from a literal '2' (cast to E) is added, then Clang warns on the
assignment itself (as opposed to on the bit-field declaration). This seems
like a more useful approach.
$ cat t.cpp
enum E : unsigned char {
e0 = 0,
e1 = 1
};
struct S {
E e : 1;
};
void f(S s) {
s.e = e0;
s.e = e1;
s.e = (E)0;
s.e = (E)1;
};
$ g++ --version
g++ (GCC) 6.1.1 20160531
...
$ g++ -c -std=c++11 -Werror t.cpp
t.cpp:6:11: error: ‘S::e’ is too small to hold all values of ‘enum E’ [-Werror]
E e : 1;
^
cc1plus: all warnings being treated as errors
[Bug c++/71543] New: [concepts] ICE on ill-formed declaration of a parameter with a constrained-type-specifier in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71543
Bug ID: 71543
Summary: [concepts] ICE on ill-formed declaration of a
parameter with a constrained-type-specifier in a
requires expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an ICE in gcc trunk r236947. The code
is ill-formed because constrained-type-specifiers are not permitted to declare
parameters in requires expressions.
$ cat t.cpp
template
concept bool C1 = true;
template
concept bool C2 = requires(C1 c1) {};
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236947
Node Kind: directory
Schedule: normal
Last Changed Author: jason
Last Changed Rev: 236947
Last Changed Date: 2016-05-31 15:49:22 -0400 (Tue, 31 May 2016)
$ gcc --version
gcc (GCC) 7.0.0 20160531 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:4:28: internal compiler error: in synthesize_implicit_template_parm, at
cp/parser.c:37843
concept bool C2 = requires(C1 c1) {};
^~
0x753793 synthesize_implicit_template_parm
../../gcc-trunk/gcc/cp/parser.c:37843
0x7539cc cp_parser_maybe_constrained_type_specifier
../../gcc-trunk/gcc/cp/parser.c:16463
0x753af8 cp_parser_nonclass_name
../../gcc-trunk/gcc/cp/parser.c:16541
0x761d41 cp_parser_type_name
../../gcc-trunk/gcc/cp/parser.c:16347
0x761d41 cp_parser_simple_type_specifier
../../gcc-trunk/gcc/cp/parser.c:16261
0x75dbdd cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:15914
0x773494 cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:12758
0x775159 cp_parser_parameter_declaration
../../gcc-trunk/gcc/cp/parser.c:20448
0x7759a4 cp_parser_parameter_declaration_list
../../gcc-trunk/gcc/cp/parser.c:20263
0x775e44 cp_parser_parameter_declaration_clause
../../gcc-trunk/gcc/cp/parser.c:20184
0x7592db cp_parser_requirement_parameter_list
../../gcc-trunk/gcc/cp/parser.c:24391
0x7592db cp_parser_requires_expression
../../gcc-trunk/gcc/cp/parser.c:24362
0x7592db cp_parser_primary_expression
../../gcc-trunk/gcc/cp/parser.c:5098
0x762775 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6688
0x760b5c cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7986
0x76ad47 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8663
0x76b333 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8764
0x76bc24 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9051
0x76c06a cp_parser_constant_expression
../../gcc-trunk/gcc/cp/parser.c:9321
0x76c8c4 cp_parser_initializer_clause
../../gcc-trunk/gcc/cp/parser.c:20837
...
[Bug c++/80746] New: [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746
Bug ID: 80746
Summary: [concepts] ICE evaluating constraints for concepts
with dependent template parameters
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
gcc 6.2/7.0/trunk reports an ICE when checking constraints involving concepts
defined with dependent template parameters:
$ cat t.cpp
template
concept bool C = true;
template T> class ct {};
struct S {
using type = int;
};
template class ct;
$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...
$ g++ -c -fconcepts t.cpp
t.cpp:3:13: internal compiler error: in tsubst, at cp/pt.c:13471
template T> class ct {};
^
0x5dc61a tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13471
0x5daf5e tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13895
0x5e6720 convert_template_argument
../../source/gcc/cp/pt.c:7623
0x5e7a10 coerce_template_parms
../../source/gcc/cp/pt.c:8098
0x6de12a resolve_variable_concept_check(tree_node*)
../../source/gcc/cp/constraint.cc:304
0x6de1d4 deduce_constrained_parameter(tree_node*, tree_node*&, tree_node*&)
../../source/gcc/cp/constraint.cc:329
0x61f41e cp_parser_maybe_constrained_type_specifier
../../source/gcc/cp/parser.c:17097
0x6333bd cp_parser_maybe_partial_concept_id
../../source/gcc/cp/parser.c:17154
0x6333bd cp_parser_template_id
../../source/gcc/cp/parser.c:15513
0x63362f cp_parser_class_name
../../source/gcc/cp/parser.c:21974
0x63dcc7 cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:6287
0x63dcc7 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:5973
0x62a650 cp_parser_constructor_declarator_p
../../source/gcc/cp/parser.c:25986
0x62a650 cp_parser_decl_specifier_seq
../../source/gcc/cp/parser.c:13332
0x6448b5 cp_parser_parameter_declaration
../../source/gcc/cp/parser.c:21204
0x645856 cp_parser_template_parameter
../../source/gcc/cp/parser.c:15133
0x645856 cp_parser_template_parameter_list
../../source/gcc/cp/parser.c:14722
0x64670b cp_parser_explicit_template_declaration
../../source/gcc/cp/parser.c:26580
0x64670b cp_parser_template_declaration_after_export
../../source/gcc/cp/parser.c:26614
0x62b369 cp_parser_declaration
../../source/gcc/cp/parser.c:12462
...
[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746 Tom Honermann changed: What|Removed |Added Blocks||67491 --- Comment #1 from Tom Honermann --- This seems likely to be related to: - Bug 67147 - [concepts] ICE on checking concept with default template arguments Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/67147] [concepts] ICE on checking concept with default template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147 --- Comment #2 from Tom Honermann --- The following bug looks likely to be related: - Bug 80746 - [concepts] ICE evaluating constraints for concepts with dependent template parameters
[Bug c++/80748] New: [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80748
Bug ID: 80748
Summary: [concepts] noexcept specifier operands are allowed but
ignored in compound requirements
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
It appears that an operand provided to the noexcept specifier in compound
requirements is ignored; the presence of any exception specification appears to
be interpreted as introducing an exception constraint:
$ cat t.cpp
template
concept bool C = requires { { T::smf() } noexcept(false); };
struct S1 {
static void smf();
};
struct S2 {
static void smf() noexcept;
};
static_assert(C);
static_assert(C);
$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...
$ g++ -c -fconcepts t.cpp
t.cpp:9:1: error: static assertion failed
static_assert(C);
^
In the above example, the expectation is that the compound requirement having a
'noexcept(false)' specifier will confer no exception constraint requirement and
that both S1 and S2 should satisfy constraint checks. However, S1 is rejected.
The test case above is ill-formed according to the Concepts TS (N4641) given
that compound requirements are specified to only accept an optional 'noexcept'
specifier (without operands):
§ 5.1.4.3 Compound requirements [expr.prim.req.compound]
compound-requirement:
{ expression } noexcept[opt] trailing-return-type[opt] ;
gcc allows an operand to be specified, but appears not to evaluate it. If the
intent of the TS is to disallow operands to the noexcept specifier in compound
requirements, then gcc should reject them. Otherwise, if the intent of the TS
is to allow operands, then gcc should evaluate them and conditionally apply
exception constraints (and an issue opened with the Concepts TS).
[Bug c++/80749] New: [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80749
Bug ID: 80749
Summary: [concepts] noexcept specifier operands are allowed but
ignored in compound requirements
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
It appears that an operand provided to the noexcept specifier in compound
requirements is ignored; the presence of any exception specification appears to
be interpreted as introducing an exception constraint:
$ cat t.cpp
template
concept bool C = requires { { T::smf() } noexcept(false); };
struct S1 {
static void smf();
};
struct S2 {
static void smf() noexcept;
};
static_assert(C);
static_assert(C);
$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...
$ g++ -c -fconcepts t.cpp
t.cpp:9:1: error: static assertion failed
static_assert(C);
^
In the above example, the expectation is that the compound requirement having a
'noexcept(false)' specifier will confer no exception constraint requirement and
that both S1 and S2 should satisfy constraint checks. However, S1 is rejected.
The test case above is ill-formed according to the Concepts TS (N4641) given
that compound requirements are specified to only accept an optional 'noexcept'
specifier (without operands):
§ 5.1.4.3 Compound requirements [expr.prim.req.compound]
compound-requirement:
{ expression } noexcept[opt] trailing-return-type[opt] ;
gcc allows an operand to be specified, but appears not to evaluate it. If the
intent of the TS is to disallow operands to the noexcept specifier in compound
requirements, then gcc should reject them. Otherwise, if the intent of the TS
is to allow operands, then gcc should evaluate them and conditionally apply
exception constraints (and an issue opened with the Concepts TS).
[Bug c++/80750] New: [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750
Bug ID: 80750
Summary: [concepts] noexcept specifier operands are allowed but
ignored in compound requirements
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
It appears that an operand provided to the noexcept specifier in compound
requirements is ignored; the presence of any exception specification appears to
be interpreted as introducing an exception constraint:
$ cat t.cpp
template
concept bool C = requires { { T::smf() } noexcept(false); };
struct S1 {
static void smf();
};
struct S2 {
static void smf() noexcept;
};
static_assert(C);
static_assert(C);
$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...
$ g++ -c -fconcepts t.cpp
t.cpp:9:1: error: static assertion failed
static_assert(C);
^
In the above example, the expectation is that the compound requirement having a
'noexcept(false)' specifier will confer no exception constraint requirement and
that both S1 and S2 should satisfy constraint checks. However, S1 is rejected.
The test case above is ill-formed according to the Concepts TS (N4641) given
that compound requirements are specified to only accept an optional 'noexcept'
specifier (without operands):
§ 5.1.4.3 Compound requirements [expr.prim.req.compound]
compound-requirement:
{ expression } noexcept[opt] trailing-return-type[opt] ;
gcc allows an operand to be specified, but appears not to evaluate it. If the
intent of the TS is to disallow operands to the noexcept specifier in compound
requirements, then gcc should reject them. Otherwise, if the intent of the TS
is to allow operands, then gcc should evaluate them and conditionally apply
exception constraints (and an issue opened with the Concepts TS).
[Bug c++/80748] [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80748 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tom Honermann --- Closing as a duplicate of bug 80750 (web server connectivity issues resulted in multiple submissions). *** This bug has been marked as a duplicate of bug 80750 ***
[Bug c++/80750] [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750 --- Comment #1 from Tom Honermann --- *** Bug 80748 has been marked as a duplicate of this bug. ***
[Bug c++/80750] [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750 --- Comment #2 from Tom Honermann --- *** Bug 80749 has been marked as a duplicate of this bug. ***
[Bug c++/79759] [concepts] ICE in tsubst, at cp/pt.c:13509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79759 --- Comment #2 from Tom Honermann --- This looks to be directly related to the following reports: - Bug 80746 - [concepts] ICE evaluating constraints for concepts with dependent template parameters - Bug 67147 - [concepts] ICE on checking concept with default template arguments
[Bug c++/81139] Non-deduced return type in abbreviated function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81139 --- Comment #1 from Tom Honermann --- Bug 69448 appears to be related.
[Bug c++/69448] Abbreviated function templates with deduced return type still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69448 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #1 from Tom Honermann --- Bug 81139 appears to be related.
[Bug c++/81198] New: [concepts] Same type constraints not enforced for constrained-type-specifiers specified in trailing return types of abbreviated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81198
Bug ID: 81198
Summary: [concepts] Same type constraints not enforced for
constrained-type-specifiers specified in trailing
return types of abbreviated functions
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The Concepts TS (N4641) states the following in 7.1.6.4 [dcl.spec.auto] p4
(this section is now 10.1.7.4 in the WP):
"A constrained-type-specifier C1 within the declared return type of an
abbreviated function template declaration does not designate a placeholder if
its introduced constraint-expression (7.1.6.4.2) is determined to be
equivalent, using the rules in 14.6.6.1 for comparing expressions, to the
introduced constraint-expression for a constrained-type-specifier C2 in the
parameter-declaration-clause of that function declaration. Instead, C1 is
replaced by the template parameter invented for C2 (8.3.5)."
Gcc implements this behaviour (with an exception reported in bug 81139) for
abbreviated functions that do not specify a trailing return type, but not for
those that do:
$ cat t.cpp
template concept bool C = true;
template class ct {};
ct af1(C) { return ct{}; }
auto af2(C) -> ct { return ct{}; }
auto v1 = af1('c'); // template instantiation fails.
auto v2 = af2('c'); // template instantiation succeeds.
$ g++ --version
g++ (GCC) 7.1.0
...
$ g++ -c -fconcepts t.cpp
t.cpp: In instantiation of ‘ct af1(auto:1) [with auto:1 = char]’:
t.cpp:5:18: required from here
t.cpp:3:31: error: could not convert ‘ct{}’ from ‘ct’ to ‘ct’
ct af1(C) { return ct{}; }
^
The expected behaviour is that both template instantiations fail.
[Bug c++/81270] New: [concepts] ill-formed code with a constrained variable declaration with multiple declarators with different deduced types not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81270
Bug ID: 81270
Summary: [concepts] ill-formed code with a constrained variable
declaration with multiple declarators with different
deduced types not rejected
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The Concepts TS (N4674) updates § 10.1.7.4 [dcl.spec.auto] paragraph 9
(paragraph 7 in the current WP) to state:
> If the init-declarator-list contains more than one init-declarator, they
> shall all form declarations of variables. The type of each declared
> variable is determined by placeholder type deduction (10.1.7.4.1), and if
> the type that replaces the declared variable type or return type is not
> the same in each deduction, the program is ill-formed.
gcc 7.1.0 fails to diagnose the following code that is ill-formed due to a
different type being deduced for each of the v1 and v2 declarators:
$ cat t.cpp
template concept bool C = true;
C v1 = 1, v2 = nullptr; // Ill-formed.
// Following code to demonstrate that the types of v1 and v2 are deduced
// to different types.
template struct is_same {
static constexpr bool value = false;
};
template struct is_same {
static constexpr bool value = true;
};
static_assert(is_same::value);
static_assert(is_same::value);
$ g++ --version
g++ (GCC) 7.1.0
...
$ g++ -c -fconcepts t.cpp
The expectation is that gcc reject the above code as it does if the declared
variable type C is replaced with auto:
$ cat t2.cpp
auto v1 = 1, v2 = nullptr;
$ g++ -c -fconcepts t2.cpp
t2.cpp:1:1: error: inconsistent deduction for ‘auto’: ‘int’ and then
‘std::nullptr_t’
auto v1 = 1, v2 = nullptr;
^~~~
[Bug c++/65552] New: [c++-concepts] Constraint checking regression for concepts with multiple type requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65552
Bug ID: 65552
Summary: [c++-concepts] Constraint checking regression for
concepts with multiple type requirements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
I built the latest revision of the gcc c++-concepts branch (r221648) last night
and encountered a regression in constraint checking for concepts that specify
multiple type requirements.
Constraint checking only fails if a requires expression specifies multiple type
requirements. Placing the type constraints in distinct requires expressions
suffices to work around the problem.
$ cat t.cpp
template
concept bool Concept() {
return requires () {
typename T::member_type1;
#if WORKAROUND
}
&& requires () {
#endif
typename T::member_type2;
};
}
struct model {
using member_type1 = int;
using member_type2 = int;
};
template
struct S {};
S s;
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221648
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221633
Last Changed Date: 2015-03-24 09:36:27 -0400 (Tue, 24 Mar 2015)
$ g++ -c -std=c++1z t.cpp
t.cpp:18:8: error: template constraint failure
S s;
^
t.cpp:18:8: note: constraints not satisfied
t.cpp:18:8: note: concept ‘Concept()’ was not satisfied
$ g++ -c -std=c++1z t.cpp -DWORKAROUND
[Bug c++/65575] New: [c++-concepts] Parse error for requires clause on functions that return a reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575 Bug ID: 65575 Summary: [c++-concepts] Parse error for requires clause on functions that return a reference type Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net Encountered with the latest revision of the gcc c++-concepts branch (r221681). Parse errors are issued for function declarations that specify a requires clause and return a reference type. The parse error occurs whether the function return type is specifed with a trailing return type or not. The error occurs for member functions as well as non-member functions. A test case follows. Changing the return type of f() from int& to just int avoids the error. Replacing the return type with a type alias for int& also avoids the problem. $ svn info # From my local svn gcc repo. Path: . URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 221681 Node Kind: directory Schedule: normal Last Changed Author: asutton Last Changed Rev: 221669 Last Changed Date: 2015-03-25 14:07:42 -0400 (Wed, 25 Mar 2015) $ cat t.cpp template concept bool C = true; auto f() -> int& requires C; $ g++ -c -std=c++1z t.cpp t.cpp:3:16: error: requires clause after non-function declaration auto f() -> int& requires C; ^
[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575 --- Comment #2 from Tom Honermann --- r221695 does correct the specific test case in comment 0. However, I'm still seeing similar errors for function declarations that don't specify the return type with a trailing return type: $ svn info # From my local svn gcc repo. Path: . URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 221697 Node Kind: directory Schedule: normal Last Changed Author: asutton Last Changed Rev: 221695 Last Changed Date: 2015-03-26 09:35:54 -0400 (Thu, 26 Mar 2015) $ cat t2.cpp template concept bool C = true; int& f() requires C; $ g++ -c -std=c++1z t2.cpp t2.cpp:3:10: error: expected initializer before ‘requires’ int& f() requires C; ^
[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #5 from Tom Honermann ---
r221733 seems to address the case in comment 2 for me.
I have one more for you. This one is a little different (no return type
involved), so let me know if you want me to open a different bug for it.
$ cat t3.cpp
struct S {
S() = default requires true;
};
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221742
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221733
Last Changed Date: 2015-03-27 10:44:22 -0400 (Fri, 27 Mar 2015)
$ g++ -c -std=c++1z t3.cpp
t3.cpp:2:11: error: expected ‘;’ at end of member declaration
S() = default requires true;
^
t3.cpp:2:19: error: expected unqualified-id before ‘requires’
S() = default requires true;
^
[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tom Honermann --- (In reply to Andrew Sutton from comment #6) > The requires-clause comes before the = default (the = xxx) is considered > part of the function definition. So: > > void f() requires true = default; Ah, thank you. The syntax I used is accepted by a long ago built gcc revision (r211824) (and that old build doesn't accept the syntax above). Closing this bug as resolved/fixed as of r221733. Thank you!
[Bug c++/65634] New: [c++-concepts] ICE in check_noexcept_r() for a noexcept constraint on a static member function call requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634
Bug ID: 65634
Summary: [c++-concepts] ICE in check_noexcept_r() for a
noexcept constraint on a static member function call
requirement
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221742).
An internal compiler error occurs when a compound-requirement expression
specifies a noexcept static member function call requirement. The ICE only
seems to occur when performing a constraint check on a member type on behalf of
another concept. Changing the return type of M1::smf() below does not affect
whether an ICE occurs, but does affect the error message that is generated
(instead of void_type, one might see integer_type, reference_type, etc...).
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221742
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221733
Last Changed Date: 2015-03-27 10:44:22 -0400 (Fri, 27 Mar 2015)
$ cat t.cpp
template
concept bool C1() {
return requires () {
{ T::smf() } noexcept;
};
}
struct M1 {
static void smf() noexcept;
};
template
concept bool C2() {
return C1();
}
struct M2 {
using type = M1;
};
static_assert(C2(), "");
$ g++ -c -std=c++1z t.cpp
t.cpp:12:32: internal compiler error: tree check: expected function_type or
method_type, have void_type in check_noexcept_r, at cp/except.c:1181
return C1();
^
0xf1faec tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-c++-concepts2/c++-concepts/gcc/tree.c:9296
0x7758c0 tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc-c++-concepts2/c++-concepts/gcc/tree.h:2865
0x7758c0 check_noexcept_r
../../gcc-c++-concepts2/c++-concepts/gcc/cp/except.c:1181
0xf40582 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
../../gcc-c++-concepts2/c++-concepts/gcc/tree.c:11092
0xf431c8 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set*))
../../gcc-c++-concepts2/c++-concepts/gcc/tree.c:11422
0x77552f expr_noexcept_p(tree_node*, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/except.c:1255
0x829c7a check_exception_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1713
0x829c7a check_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1798
0x82a0b3 check_conjunction
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1747
0x82a0b3 check_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1804
0x829ecd check_parameterized_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1730
0x829ecd check_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1801
0x620cc3 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/call.c:4161
0x79f4da finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/semantics.c:2407
0x67e887 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:15789
0x682b56 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:14970
0x82da7f lift_function_definition
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:340
0x82db43 evaluate_function_concept(tree_node*, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1885
0x620cc3 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/call.c:4161
0x79f4da finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/semantics.c:2407
[Bug c++/65635] New: [c++-concepts] ICE in cp_tree_equal() during class template partial specialization constraint matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635
Bug ID: 65635
Summary: [c++-concepts] ICE in cp_tree_equal() during class
template partial specialization constraint matching
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221742).
An internal compiler error occurs when matching constrained class template
partial specializations.
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221742
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221733
Last Changed Date: 2015-03-27 10:44:22 -0400 (Fri, 27 Mar 2015)
$ cat t.cpp
template
concept bool Subsumed() {
return requires () { typename T::type1; };
}
template
concept bool Subsuming() {
return Subsumed()
&& requires () { typename T::type2; };
}
struct M {
using type1 = int;
using type2 = int;
};
template
concept bool C() {
return requires () {
typename T::force_instantiation;
};
}
template
struct TM;
template
struct TM {};
template
struct TM {};
static_assert(C>(), "");
$ g++ -c -std=c++1z t.cpp
t.cpp:20:28: internal compiler error: in cp_tree_equal, at cp/tree.c:3037
typename T::force_instantiation;
^
0x7c7a6f cp_tree_equal(tree_node*, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/tree.c:3037
0x7c7a0e cp_tree_equal(tree_node*, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/tree.c:3028
0x82f7d2 match_terms
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:384
0x82f7d2 subsumes_atomic_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:394
0x82f7d2 subsumes_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:445
0x82f94f subsumes_conjunction
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:406
0x82f94f subsumes_constraint
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:439
0x82faee subsumes_constraints_nonnull
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:463
0x82faee subsumes(tree_node*, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/logic.cc:481
0x82f554 more_constrained(tree_node*, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:2089
0x6899dd most_specialized_partial_spec
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:20019
0x6afb0c instantiate_class_template_1
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:9634
0x6afb0c instantiate_class_template(tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:10174
0x74f2cb complete_type(tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/typeck.c:146
0x68bc7d tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:13001
0x67574b tsubst_decl
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:11807
0x68b9c6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:12388
0x82eb81 tsubst_type_requirement
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1390
0x82eb81 tsubst_requirement
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1426
0x82eb81 tsubst_requirement_body
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1446
[Bug c++/65636] New: [c++-concepts] ICE (Segmentation fault) when a type requirement names a typedef or type alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636
Bug ID: 65636
Summary: [c++-concepts] ICE (Segmentation fault) when a type
requirement names a typedef or type alias
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221742).
An internal compiler error occurs when a type requirement names a typedef or
type alias. I suspect this code is ill-formed - a proper diagnostic is
produced if a builtin type (ie, 'int') is named in lieu of the type alias.
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221742
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221733
Last Changed Date: 2015-03-27 10:44:22 -0400 (Fri, 27 Mar 2015)
$ cat t.cpp
using TD = int;
template
concept bool C() {
return requires () {
typename TD;
};
}
static_assert(C(), "");
$ g++ -c -std=c++1z t.cpp
t.cpp:1:13: internal compiler error: Segmentation fault
typedef int TD;
^
0xcc91ef crash_signal
../../gcc-c++-concepts2/c++-concepts/gcc/toplev.c:383
0x6754ff tsubst_decl
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:11859
0x68b9c6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:12388
0x82eb81 tsubst_type_requirement
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1390
0x82eb81 tsubst_requirement
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1426
0x82eb81 tsubst_requirement_body
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1446
0x82eb81 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1476
0x67ca83 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:16301
0x682b56 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/pt.c:14970
0x82da7f lift_function_definition
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:340
0x82db43 evaluate_function_concept(tree_node*, tree_node*)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/constraint.cc:1885
0x620cc3 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/call.c:4161
0x79f4da finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-c++-concepts2/c++-concepts/gcc/cp/semantics.c:2407
0x7269c7 cp_parser_postfix_expression
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:6448
0x729219 cp_parser_unary_expression
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:7511
0x729e07 cp_parser_binary_expression
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:8245
0x72a61f cp_parser_assignment_expression
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:8503
0x72a9f5 cp_parser_constant_expression
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:8749
0x72aad4 cp_parser_static_assert
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:12308
0x721399 cp_parser_block_declaration
../../gcc-c++-concepts2/c++-concepts/gcc/cp/parser.c:11564
[Bug c++/65681] New: [c++-concepts] spurious ambiguous template instantiation error; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681
Bug ID: 65681
Summary: [c++-concepts] spurious ambiguous template
instantiation error; regression from r211824
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates what I believe to be a spurious error in
resolving constrained class template partial specializations. This appears to
be a regression introduced at some point. The error occurs using a gcc r221861
based build. I have an old gcc build (r211824) that compiles it successfully.
The test case is rather long. It may be possible to reduce it a little bit
more, but it seems to be a little fragile as is. For example, changing concept
C to specify a type requirement rather than a member function call requirement
suffices to avoid the error. Additionally, swapping the requirements of CA1
with CB1 and the type alias targets of MA1 and MB1 (while retaining the
existing dependent type names) suffices to avoid the error.
The test case defines two parallel concept hierarchies, CA[1-3] and CB[1-3],
with accompanying models MA[1-3] and MB[1-3]. Class template S defines the
problematic constrained partial specializations. The specializations are
intended to select alternate behavior when the type for T1 is less refined than
the type for T2, in a covariant sense.
$ cat t.cpp
template
concept bool C() {
return requires (T t) {
{ t.mf() }
};
}
struct MC {
void mf();
};
static_assert(C(), "");
template
concept bool CA1() {
return C();
}
template
concept bool CA2() {
return CA1()
&& requires () {
typename T::ca2_type;
};
}
template
concept bool CA3() {
return CA2()
&& requires () {
typename T::ca3_type;
};
}
template
concept bool CB1() {
return requires () {
typename T::cb1_type;
};
}
template
concept bool CB2() {
return CB1()
&& requires () {
typename T::cb2_type;
};
}
template
concept bool CB3() {
return CB2()
&& requires () {
typename T::cb3_type;
};
}
struct MA1 {
using ca1_type = MC;
};
struct MA2 : MA1 {
using ca2_type = int;
};
struct MA3 : MA2 {
using ca3_type = int;
};
static_assert(CA1(), "");
static_assert(CA2(), "");
static_assert(CA3(), "");
struct MB1 {
using cb1_type = int;
};
struct MB2 : MB1 {
using cb2_type = int;
};
struct MB3 : MB2 {
using cb3_type = int;
};
static_assert(CB1(), "");
static_assert(CB2(), "");
static_assert(CB3(), "");
template
struct S;
template
struct S { // Specialization #1
static constexpr int value = 1;
};
template
requires ! CA2()
struct S { // Specialization #2
static constexpr int value = 2;
};
template
requires ! CA3()
struct S { // Specialization #3
static constexpr int value = 3;
};
S s11;
S s12;
S s13;
S s21;
S s22;
S s23;
S s31;
S s32;
S s33;
static_assert(S::value == 1, "");
static_assert(S::value == 2, "");
static_assert(S::value == 2, "");
static_assert(S::value == 1, "");
static_assert(S::value == 1, "");
static_assert(S::value == 3, "");
static_assert(S::value == 1, "");
static_assert(S::value == 1, "");
static_assert(S::value == 1, "");
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221861
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221857
Last Changed Date: 2015-04-03 12:47:32 -0400 (Fri, 03 Apr 2015)
# Using the gcc build above, an error is produced.
$ g++ -Wfatal-errors -c -std=c++1z t.cpp
t.cpp:101:12: error: ambiguous template instantiation for ‘struct S’
S s23;
^
compilation terminated due to -Wfatal-errors.
# Using an old gcc r211824 based build, compilation is successful (note
# that this old build required -std=c++1y to enable support for concepts.
$ g++ -c -std=c++1y t.cpp
$ echo $?
0
[Bug c++/65635] [c++-concepts] ICE in cp_tree_equal() during class template partial specialization constraint matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Honermann --- Confirmed fixed with r221861. Changing status to resolved/fixed.
[Bug c++/65635] [c++-concepts] ICE in cp_tree_equal() during class template partial specialization constraint matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635 Tom Honermann changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from Tom Honermann --- Verified fixed with r221861. Changing status to verified/fixed.
[Bug c++/65634] [c++-concepts] ICE in check_noexcept_r() for a noexcept constraint on a static member function call requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634 --- Comment #3 from Tom Honermann --- Confirmed fixed with r221861. I'll leave the bug open though since comment 2 is requesting additional followup.
[Bug c++/65636] [c++-concepts] ICE (Segmentation fault) when a type requirement names a typedef or type alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636 --- Comment #3 from Tom Honermann --- Confirmed fixed with r221861. I'll leave the bug open though since comment 2 is requesting additional followup.
[Bug c++/65681] [c++-concepts] spurious ambiguous template instantiation error; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Honermann --- Thanks! This issue appears to be resolved for me. Tested with r38.
[Bug c++/65848] New: [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848
Bug ID: 65848
Summary: [c++-concepts] High memory usage and compilation times
for subsuming concept chains; regression from r211824
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates high CPU and memory utilization during
compilation when compiled with gcc r38. I have an old gcc build (r211824)
that compiles this test case quickly with low memory usage. Details are below
the test case.
The performance issue depends on use of the type trait templates. Replacing
references to them with 'true' suffices to enable the code to be quickly
compiled (though possibly with still higher resource usage then with an r211824
build, I didn't measure). Likewise, reducing the length of the CN concept
chain or the number of types for which concepts are asserted has an exponential
effect on resource usage. Increasing the length of the concept chain much
further results in compilations that will not complete successfully on my
modest hardware (Lenovo T420 laptop with 8GB ram).
I attempted to remove the dependency on the type_traits header, but the number
of entities I would have needed to add to the test case below would have made
the test case much longer. Simplifying their implementation to keep the test
case small greatly reduced resource usage. It seems their implementation is
relevant to the issue.
$ cat t.cpp
#include
template
concept bool Destructible() {
return std::is_destructible::value;
}
template
concept bool Constructible() {
return Destructible() && std::is_constructible::value;
}
template
concept bool Move_constructible() {
return Constructible();
}
template
concept bool Copy_constructible() {
return Move_constructible() && Constructible();
}
template
concept bool Assignable() {
return std::is_assignable::value;
}
template
concept bool Move_assignable() {
return Assignable();
}
template
concept bool Copy_assignable() {
return Move_assignable() && Assignable();
}
template
concept bool Copyable() {
return Copy_constructible() && Copy_assignable();
}
template
concept bool C1() { return Copyable(); }
template
concept bool C2() { return C1(); }
template
concept bool C3() { return C2(); }
template
concept bool C4() { return C3(); }
template
concept bool C5() { return C4(); }
template
concept bool C6() { return C5(); }
template
concept bool C7() { return C6(); }
template
concept bool C8() { return C7(); }
template
concept bool C9() { return C8(); }
template
concept bool C10() { return C9(); }
template
concept bool C11() { return C10(); }
struct S1 {};
struct S2 {};
struct S3 {};
struct S4 {};
struct S5 {};
struct S6 {};
static_assert(C11(), "");
static_assert(C11(), "");
static_assert(C11(), "");
static_assert(C11(), "");
static_assert(C11(), "");
static_assert(C11(), "");
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 38
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 36
Last Changed Date: 2015-04-20 09:43:31 -0400 (Mon, 20 Apr 2015)
Timing details for both the r38 gcc build above and an old r211824 based
build follow. The timing data was produced by /usr/bin/time on an Ubuntu 12.04
system. The data below was produced with a hot cache in each case.
# Using gcc r38, compilation time and memory usage is significant:
$ /usr/bin/time -v g++ -c -std=c++1z t.cpp
Command being timed: "g++ -c -std=c++1z t.cpp"
User time (seconds): 17.73
System time (seconds): 0.88
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:18.67
...
Maximum resident set size (kbytes): 8409216
...
Minor (reclaiming a frame) page faults: 527712
...
# Using an old gcc r211824, compilation completes quickly (note
# that this old build required -std=c++1y to enable support for concepts).
$ /usr/bin/time -v g++ -c -std=c++1y t.cpp
Command being timed: "g++ -c -std=c++1y t.cpp"
User time (seconds): 0.05
System time (seconds): 0.00
Percent of CPU this job got: 88%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.06
...
Maximum resident set size (kbytes): 63936
...
Minor (reclaiming a frame) page faults: 6107
...
[Bug c++/65854] New: [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854
Bug ID: 65854
Summary: [c++-concepts] Type constraint satisfaction error for
type aliases; regression from r211824
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates what I believe to be an error in type
constraint satisfaction involving type aliases. I believe the code should be
rejected with the noted error. I have an old gcc build (r211824) that does
reject it (though the 'typename' keyword in the concept definition must be
removed for the compiler to reject it for the correct reason). gcc r222333
(incorrectly) accepts it.
The test case defines a binary type trait template class (BTT), an alias
template that references it (Alias), a concept (C) that specifies a type
constraint using the alias, and declares a template function (f) that requires
the concept for its template parameters. The call to f() should be
rejected due to a failure of the type constraint in C (BTT::type
won't exist), but gcc r222333 fails to reject.
Changing the concept to bypass the template alias and require 'typename
BTT::type' instead suffices for gcc r222333 to correctly reject the
code.
$ cat t.cpp
template
struct BTT {};
template
struct BTT {
using type = int;
};
template
using Alias = typename BTT::type;
template
concept bool C() {
return requires() {
typename Alias;
};
}
template
requires C()
int f();
auto i = f(); // error: cannot call function
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 222333
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 222332
Last Changed Date: 2015-04-22 12:08:55 -0400 (Wed, 22 Apr 2015)
$ g++ -c -std=c++1z t.cpp
# Using an older gcc r211824 build (and having removed the 'typename' keyword
# preceding Alias in the concept definition that this old build didn't allow),
# the code is rejected (though the error message is a little off). (note
# that this old build required -std=c++1y to enable support for concepts).
$ g++ -c -std=c++1y t.cpp
t.cpp:22:23: error: no matching function for call to ‘f()’
auto i = f();
^
t.cpp:20:5: note: candidate: template int f()
int f();
^
t.cpp:20:5: note: template argument deduction/substitution failed:
t.cpp:20:5: note: constraints not satisfied [with T1 = char; T2 = int]
t.cpp:20:5: note: failure in constraint ‘template
constexpr bool C()’
t.cpp:20:5: note: ‘BTT::Alias’ does not name a valid type
[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Honermann --- Thank you. Confirmed fixed with r222332. My resource usage compiling the test case now closely matches the usage noted in comment 2. (In reply to Andrew Sutton from comment #1) > This is caused by the use of a concept outside of a requires clause -- it's > still a bug though. The TS doesn't actually include wording that would allow > this program to be valid. Ah, I wasn't aware of that restriction. > Unfortunately, the first thing people do when they have concepts it to write > tests that statically assert them, so I've been extending the proposal to > make that valid. I think that is actually not so unfortunate. Statically asserting concept models has helped me find numerous issues in my own code. I'm glad to hear the proposal is being extended to cover this.
[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854 Tom Honermann changed: What|Removed |Added Summary|[c++-concepts] Type |[c++-concepts] Type |constraint satisfaction |constraint satisfaction |error for type aliases; |error for type aliases; |regression from r211824 |regression from r211591 --- Comment #1 from Tom Honermann --- A correction. I've been reading the svn info details incorrectly. The old gcc build I have that accepts this code is r211591, not r211824. Updated the summary.
[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Honermann --- Thank you! I confirmed that this is corrected with r222769. Changing status to resolved/fixed.
[Bug c++/66091] New: [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091
Bug ID: 66091
Summary: [c++-concepts] Overloading of member operators based
on constraints rejected; regression from r211591
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
The following test case was accepted by r211591 of the c++-concepts branch, but
is rejected by r222769. My interpretation of N4377 is that this test case
should be accepted.
$ cat t.cpp
template
concept bool C1() {
return requires() { typename T::type1; };
}
template
concept bool C2() {
return C1()
&& requires() { typename T::type2; };
}
template
struct S {
S& operator++()
{ return *this; }
S& operator++()
requires C2()
{ return *this; }
};
# Compiling with r222769:
$ g++ -c -std=c++1z t.cpp
t.cpp:14:8: error: ‘S& S::operator++()’ cannot be overloaded
S& operator++()
^
t.cpp:12:8: error: with ‘S& S::operator++()’
S& operator++()
^
[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091 Tom Honermann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Honermann --- Thanks! Confirmed fixed in r223061.
[Bug c++/68093] New: [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093
Bug ID: 68093
Summary: [concepts] friend function declarations that differ
only by constraints are rejected as redefinitions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
I believe the following code is intended to be well-formed according to P0121r0
[1]. gcc trunk (r229299) currently rejects it.
$ cat t.cpp
struct S1 {};
struct S2 { using t1 = int; };
template
concept bool Has_t1() {
return requires () { typename T::t1; };
}
template
struct TS {
friend void f(TS) {}
friend void f(TS) requires Has_t1() {} // Unexpected error: redefinition
};
TS ts1;
TS ts2;
auto x = []{
f(ts1);
f(ts2);
};
$ gcc --version
gcc (GCC) 6.0.0 20151025 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -c -std=c++1z t.cpp
t.cpp: In instantiation of ‘struct TS’:
t.cpp:12:8: required from here
t.cpp:10:17: error: redefinition of ‘void f(TS)’
friend void f(TS) requires Has_t1() {} // Unexpected error:
redefinition
^
t.cpp:9:17: note: ‘void f(TS)’ previously defined here
friend void f(TS) {}
^
t.cpp: In instantiation of ‘struct TS’:
t.cpp:13:8: required from here
t.cpp:10:17: error: redefinition of ‘void f(TS)’
friend void f(TS) requires Has_t1() {} // Unexpected error:
redefinition
^
t.cpp:9:17: note: ‘void f(TS)’ previously defined here
friend void f(TS) {}
^
[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0121r0.pdf
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #9 from Tom Honermann ---
Note that call of the implicitly-defaulted copy constructor using
list-initialization is accepted for aggregate data members (verified using gcc
trunk (5.0 (c++-concepts branch), svn revision 219158))
$ cat t.cpp
struct base {
};
struct encapsulate {
encapsulate(const base &state)
: b{state} // accepted.
{}
base b;
};
void f(base b) {
encapsulate e{b};
}
[Bug c++/69235] New: [concepts] Spurious ambiguous template instantiation error on oppositely constrained class template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69235
Bug ID: 69235
Summary: [concepts] Spurious ambiguous template instantiation
error on oppositely constrained class template
specializations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
I believe the following test case is well-formed, but gcc trunk (r232017) emits
an "ambiguous template instantiation" error for the X specialization. The
ambiguity arises from the oppositely constrained partial specializations of
template class X. Since the partial specializations are oppositely
constrained, an ambiguity should not be possible.
The test case exhibits some fragility. The error only occurs when the requires
expression in the C concept definition specifies a constrained-type-specifer as
the trailing-return-type of the compound-requirement at #3; substituting a
non-placeholder simple-type-specifier as is done at #2 by compiling with the
AVOID_BOOLEAN_CONCEPT macro defined enables successful compilation.
Additionally, compilation is successful (with or without AVOID_BOOLEAN_CONCEPT
defined) if the code is adjusted at #6 to pass a fundamental type (char)
instead of S as the template argument to X, and at #4 and #5 to pass T rather
than the member type T::type in the requires clause.
$ cat t.cpp
template
concept bool
Boolean()
{
return requires(T t)
{
{ t } -> bool // #1
};
}
template
concept bool
C() {
return requires (T t)
{
#if AVOID_BOOLEAN_CONCEPT
{ t } -> bool;// #2
#else
{ t } -> Boolean; // #3
#endif
};
}
template
struct X;
template
requires ! C() // #4
struct X {
using type = int;
};
template
requires C()// #5
struct X {
using type = int;
};
struct S {
using type = char;
};
void f() {
X::type x; // #6
}
$ svn info # From my local svn gcc repo.
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 232017
Node Kind: directory
Schedule: normal
Last Changed Author: nathan
Last Changed Rev: 232017
Last Changed Date: 2015-12-31 09:07:52 -0500 (Thu, 31 Dec 2015)
# Using the gcc version above, the error is produced:
$ g++ -c -std=c++1z t.cpp
t.cpp: In function ‘void f()’:
t.cpp:42:9: error: ambiguous template instantiation for ‘struct X’
X::type x;
^~
t.cpp:28:8: note: candidates are: template requires
predicate(!(C)()) struct X [with T = S]
struct X {
^~~~
t.cpp:33:8: note: template requires
predicate((C)()) struct X [with T = S]
struct X {
^~~~
t.cpp:42:5: error: incomplete type ‘X’ used in nested name specifier
X::type x;
^~~~
# Compiling with AVOID_BOOLEAN_CONCEPT defined avoids the spurious error:
$ g++ -c -std=c++1z t.cpp -DAVOID_BOOLEAN_CONCEPT; echo $?
0
[Bug c++/67565] [concepts] Very slow compile time and high memory usage with complex concept definitions, even if unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67565
Tom Honermann changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com,
||asutton at gcc dot gnu.org,
||tom at honermann dot net
--- Comment #2 from Tom Honermann ---
I'm also experiencing this issue and finding it to be rather catastrophic at
present. I'm currently using gcc trunk (r232017).
I distilled the following test case from my project before coming across this
bug report. The test cases shares some properties with the one in comment 0;
no actual instantiations of the class template (or function for Adrian's test
case) are needed to trigger the issue, both conjunctions and disjunctions are
present.
This test case includes some conditional compilation options intended to
demonstrate that syntactic transformations that should have no semantic affect
have dramatic compile time performance impact; search for GO_FAST1 and
GO_FAST2. Additionally, defining the GO_SLOWER1 macro demonstrates a means of
scaling the performance impact.
$ cat t.cpp
$ cat t.cpp
template
concept bool
C1()
{
return sizeof(T) > 4;
}
template
constexpr bool
f1()
{
return C1();
}
template
constexpr bool
f2()
{
return f1()
|| f1()
|| f1()
|| f1()
|| f1();
}
template
concept bool
C2()
{
#if GO_FAST1
return f2();
#else
return f1()
|| f1()
|| f1()
|| f1()
#if GO_SLOWER1
|| f1()
#endif
|| f1();
#endif
}
template
concept bool C3() {
return C2()
&& (C1()
|| C1()
|| C1());
}
template
concept bool C4() {
return C3()
&& C3();
}
template
concept bool C5() {
return C4();
}
template
concept bool C6() {
return C5()
&& true;
}
#if GO_FAST2
template
requires C4()
&& C5()
&& C6()
#else
template
requires C5()
&& C6()
#endif
struct S {
};
$ time g++ -c -std=c++1z t.cpp
real0m9.485s
user0m8.672s
sys 0m0.820s
$ time g++ -c -std=c++1z t.cpp -DGO_FAST1
real0m0.027s
user0m0.008s
sys 0m0.008s
$ time g++ -c -std=c++1z t.cpp -DGO_FAST2
real0m0.064s
user0m0.056s
sys 0m0.000s
$ time g++ -c -std=c++1z t.cpp -DGO_SLOWER1
real0m30.464s
user0m26.100s
sys 0m2.832s
The GO_SLOWER1 test peaks at about 10G of virtual memory for me.
[Bug c++/71221] [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221 --- Comment #3 from Tom Honermann --- This issue appears to be resolved as of r238202. I can now compile the test case from comment 0 successfully.
[Bug c++/71843] New: [concepts] Diagnostics issued for constraint satisfaction failure fail to elucidate unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71843
Bug ID: 71843
Summary: [concepts] Diagnostics issued for constraint
satisfaction failure fail to elucidate unsatisfied
constraints
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The diagnostics emitted when overload resolution fails due to constraint
satisfaction failure do not elucidate the constraints that were not satisfied.
For non-trivial concepts, it can be difficult and tedious for a user to
determine exactly why a given type did not satisfy a set of constraints.
For example, using gcc 6.1.0:
$ cat t.cpp
template
concept bool C = requires(T t) { t.i; };
template
auto f(T t) {
return t.i;
}
struct S {
};
auto x = f(S{});
$ g++ --version
g++ (GCC) 6.1.0
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:9:15: error: cannot call function ‘auto f(T) [with T = S]’
auto x = f(S{});
^
t.cpp:4:6: note: constraints not satisfied
auto f(T t) {
^
t.cpp:4:6: note: concept ‘C’ was not satisfied
The error message clearly indicates that S does not satisfy the constraints
associated with concept C, but does not explain that the reason constraint
satisfaction failed is because the expression t.i is ill-formed for an object t
of type S.
When designing types intended to model a particular concept, it is often useful
to statically assert that the type models the intended concept. Here too the
error messages are less helpful then desired:
$ cat t2.cpp
template
concept bool C = requires(T t) { t.i; };
struct S {
};
static_assert(C);
$ g++ -c -std=c++1z -fconcepts t2.cpp
t2.cpp:5:1: error: static assertion failed
static_assert(C);
^
[Bug c++/71843] [concepts] Diagnostics issued for constraint satisfaction failure fail to elucidate unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71843
--- Comment #1 from Tom Honermann ---
Created attachment 38876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38876&action=edit
Patch to elucidate failed constraints
The attached patch was provided to me by Andrew Sutton earlier this year and
applies cleanly to gcc 6 trunk (r238201).
The patch modifies the error messages emitted for constraint satisfaction
failures so that the specific constraints that were not satisfied will be
listed, up to a maximum of 7 constraints for each overload candidate.
Ideally, the number of constraints to list would be controlled by command line
options, but the patch does not currently provide such control.
Example diagnostics provided by this patch:
$ cat t.cpp
template
concept bool C = requires(T t) {
typename T::type;
t.i;
t.i2;
t.i3;
t.i4;
t.i5;
t.i6;
t.i7;
t.i8;
};
template
auto f(T t) {
return t.i;
}
struct S {
};
auto x = f(S{});
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:19:15: error: cannot call function ‘auto f(T) [with T = S]’
auto x = f(S{});
^
t.cpp:14:6: note: constraints not satisfied
auto f(T t) {
^
t.cpp:14:6: note: concept ‘C’ was not satisfied
t.cpp:2:14: note: within the concept template constexpr const bool
C [with T = S]
concept bool C = requires(T t) {
^
t.cpp:2:14: note: the required type ‘typename T::type’ would be ill-formed
t.cpp:2:14: note: the required expression ‘t.i’ would be ill-formed
t.cpp:2:14: note: the required expression ‘t.i2’ would be ill-formed
t.cpp:2:14: note: the required expression ‘t.i3’ would be ill-formed
t.cpp:2:14: note: the required expression ‘t.i4’ would be ill-formed
t.cpp:2:14: note: the required expression ‘t.i5’ would be ill-formed
t.cpp:14:6: note: ... 2 constraint errors not shown
auto f(T t) {
^
This patch does not affect the diagnostics produced for failed static
assertions of constraint satisfaction. Ideally, those diagnostics would be
improved to list specific constraints as well.
[Bug c++/67565] [concepts] Very slow compile time and high memory usage with complex concept definitions, even if unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67565 --- Comment #5 from Tom Honermann --- Nice, thanks! Using gcc r238587, I get the times below for the examples in this report. All cases are dramatically improved. Unless there is some other known issue not captured in the discussion here, it looks to me like this issue can be resolved. For the example in comment 0: $ time g++ -std=c++1z -fconcepts main.cpp real0m0.051s user0m0.040s sys 0m0.008s For the example in comment 2: $ time g++ -c -std=c++1z -fconcepts t.cpp real0m0.009s user0m0.004s sys 0m0.000s $ time g++ -c -std=c++1z -fconcepts t.cpp -DGO_FAST1 real0m0.009s user0m0.004s sys 0m0.000s $ time g++ -c -std=c++1z -fconcepts t.cpp -DGO_FAST2 real0m0.009s user0m0.000s sys 0m0.004s $ time g++ -c -std=c++1z -fconcepts t.cpp -DGO_SLOWER1 real0m0.009s user0m0.000s sys 0m0.004s Additionally, my builds of Text View [1] now complete in 0m26.140s improved from 1m35.837s. [1]: https://github.com/tahonermann/text_view
[Bug c++/71995] New: ~36% compile-time performance regression for C++ in gcc HEAD vs gcc-6-branch HEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71995
Bug ID: 71995
Summary: ~36% compile-time performance regression for C++ in
gcc HEAD vs gcc-6-branch HEAD
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
A compile-time performance degradation in gcc HEAD (r238592) vs gcc-6-branch
HEAD (r238587) was observed while verifying performance improvements for bug
67565. Though that bug was specific to C++ concepts, the performance
regression is not.
In my tests both the gcc and gcc-6-branch compilers were built using the Ubuntu
15.10 x86_64 distribution of gcc 5.2.1:
$ gcc --version
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
...
Both gcc builds were configured and built with:
$ ./configure \
CC=gcc \
CXX=g++ \
--prefix /path/to/install/... \
--disable-multilib \
--disable-bootstrap \
--enable-languages=c,c++
$ make
$ make install
The following code was used for testing:
$ cat t.cpp
/*
* Test adapted from:
* https://randomascii.wordpress.com/2014/03/10/making-compiles-slow
*/
#if !defined(SCALE_FACTOR)
#define SCALE_FACTOR 23
#endif
template
struct slow_fibonacci {
static constexpr int value =
slow_fibonacci::value +
slow_fibonacci::value;
};
template
struct slow_fibonacci {
static constexpr int value = 1;
};
template
struct slow_fibonacci {
static constexpr int value = 1;
};
constexpr int x = slow_fibonacci<0,SCALE_FACTOR>::value;
The test was performed three times at each of three scale factors for each
compiler build, the times averaged for each scale factor, and then percentages
calculated.
Compile times using the gcc trunk build:
# default SCALE_FACTOR=23
$ time g++ -c -std=c++11 t.cpp
real0m02.079s | real0m02.089s | real0m02.070s
user0m02.004s | user0m02.016s | user0m02.000s
sys 0m00.068s | sys 0m00.068s | sys 0m00.064s
# SCALE_FACTOR=25
$ time g++ -c -std=c++11 -DSCALE_FACTOR=25 t.cpp
real0m05.401s | real0m05.431s | real0m05.428s
user0m05.224s | user0m05.272s | user0m05.224s
sys 0m00.172s | sys 0m00.156s | sys 0m00.204s
# SCALE_FACTOR=27
$ time g++ -c -std=c++11 -DSCALE_FACTOR=27 t.cpp
real0m14.268s | real0m14.379s | real0m14.654s
user0m13.912s | user0m13.900s | user0m14.332s
sys 0m00.356s | sys 0m00.480s | sys 0m00.320s
Compile times using the gcc-6-branch build:
# default SCALE_FACTOR=23
$ time g++ -c -std=c++11 t.cpp
real0m01.466s | real0m01.432s | real0m01.441s
user0m01.384s | user0m01.320s | user0m01.356s
sys 0m00.076s | sys 0m00.108s | sys 0m00.080s
# SCALE_FACTOR=25
$ time g++ -c -std=c++11 -DSCALE_FACTOR=25 t.cpp
real0m04.076s | real0m04.072s | real0m04.366s
user0m03.868s | user0m03.920s | user0m04.208s
sys 0m00.204s | sys 0m00.148s | sys 0m00.152s
# SCALE_FACTOR=27
$ time g++ -c -std=c++11 -DSCALE_FACTOR=27 t.cpp
real0m10.658s | real0m10.701s | real0m10.779s
user0m10.096s | user0m10.292s | user0m10.368s
sys 0m00.560s | sys 0m00.408s | sys 0m00.412s
-+---+--+-+
SCALE_FACTOR | gcc trunk avg | gcc-6-branch avg | % change|
-+---+--+-+
23 |2.079s | 1.446s | +43.776% / -30.447% |
25 |5.420s | 4.171s | +29.945% / -23.044% |
27 | 14.434s | 10.713s | +34.734% / -25.779% |
-+---+--+-+
Averaging the percentages suggests ~36% performance overhead for gcc trunk vs
gcc-6-branch.
[Bug c++/71995] ~36% compile-time performance regression for C++ in gcc HEAD vs gcc-6-branch HEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71995 Tom Honermann changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Tom Honermann --- (In reply to Andrew Pinski from comment #1) > Can you add --enable-checking=release and try again for the trunk? Thanks, that explains it: Compile times using the gcc trunk build: # default SCALE_FACTOR=23 $ time g++ -c -std=c++11 t.cpp real0m01.427s | real0m01.442s | real0m01.430s user0m01.328s | user0m01.384s | user0m01.356s sys 0m00.092s | sys 0m00.052s | sys 0m00.068s # SCALE_FACTOR=25 $ time g++ -c -std=c++11 -DSCALE_FACTOR=25 t.cpp real0m03.969s | real0m03.978s | real0m04.008s user0m03.816s | user0m03.804s | user0m03.900s sys 0m00.148s | sys 0m00.168s | sys 0m00.104s # SCALE_FACTOR=27 $ time g++ -c -std=c++11 -DSCALE_FACTOR=27 t.cpp real0m10.735s | real0m10.757s | real0m10.873s user0m10.340s | user0m10.272s | user0m10.420s sys 0m00.392s | sys 0m00.484s | sys 0m00.452s Times are now close enough to gcc-6-branch times that I'm not going to bother calculating percentages. Closing as resolved/invalid.
[Bug c++/30277] bit-field: wrong overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277
--- Comment #4 from Tom Honermann ---
We recently got bit by this. It is still an issue in latest gcc trunk:
$ cat t.cpp
enum E : int {
e1 = 1
};
constexpr E operator-(E, E) {
return (E)99;
}
typedef struct {
E e;
E ebf : 16;
} S;
constexpr S s = { e1, e1 };
static_assert(99 == (int)(s.e-s.e),"Overload resolution failed for
non-bit-field");
static_assert(99 == (int)(s.ebf-s.ebf),"Overload resolution failed for
bit-field");
$ g++ --version
g++ (GCC) 7.0.0 20160721 (experimental)
...
$ g++ -c -std=c++11 t.cpp
t.cpp:9:14: warning: â::ebfâ is too small to hold all values
of âenum Eâ
E ebf : 16;
^~
t.cpp:13:1: error: static assertion failed: Overload resolution failed for
bit-field
static_assert(99 == (int)(s.ebf-s.ebf),"Overload resolution failed for
bit-field");
^
(I would love to be able to disable that warning as well: bug 51242)
[Bug c++/106423] New: -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 Bug ID: 106423 Summary: -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net Target Milestone: --- As demonstrated at https://godbolt.org/z/GoTqPTcM3, use of gcc's '#pragma GCC diagnostic ignored "-Wc++20-compat"' directive fails to suppress -Wc++20-compat enabled diagnostics. gcc versions 10 and up are affected. $ cat t.cpp #pragma GCC diagnostic ignored "-Wc++20-compat" int constinit; $ gcc -c -std=c++17 -Wc++20-compat t.cpp t.cpp:2:5: warning: identifier ‘constinit’ is a keyword in C++20 [-Wc++20-compat] 2 | int constinit; | ^
[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #1 from Tom Honermann --- A patch for this issue was submitted to the gcc-patches mailing list and is available at https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598736.html.
[Bug c++/106426] New: UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426 Bug ID: 106426 Summary: UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net Target Milestone: --- As demonstrated at https://godbolt.org/z/7xzWEbqb5, UTF-8 character literals in preprocessor directives are given the same type as ordinary character literals (`char` with signed or unsigned behavior dependent on target or use of the `-fsigned-char` or `-funsigned-char` option) in `char8_t` modes. In `char8_t` enabled modes (C++20 by default or when `-fchar8_t` is used), such literals should be treated as unsigned. $ cat t.cpp #if u8'\0' - 1 < 0 #error "UTF-8 character literals not unsigned in preprocessor" #endif $ gcc -c -std=c++17 -fchar8_t t.cpp t.cpp:2:2: error: #error "UTF-8 character literals not unsigned in preprocessor" 2 | #error "UTF-8 character literals not unsigned in preprocessor" | ^ $ gcc -c -std=c++20 t.cpp t.cpp:2:2: error: #error "UTF-8 character literals not unsigned in preprocessor" 2 | #error "UTF-8 character literals not unsigned in preprocessor" | ^
[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426 --- Comment #1 from Tom Honermann --- A patch for this issue was submitted to the gcc-patches mailing list with the patch series available at https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599240.html.
[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426 --- Comment #3 from Tom Honermann --- I believe this issue can be resolved as fixed via commit 053876cdbe8057210e6f4da4eec2df58f92ccd4c for the gcc 13 release.
[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #3 from Tom Honermann --- I believe this issue can be resolved as fixed via commit 60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release.
[Bug c++/71136] [concepts] Spurious 'converting overloaded function is ambiguous' error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71136 --- Comment #3 from Tom Honermann --- (In reply to Andrew Pinski from comment #2) > Hmm, clang and MSVC also reject the code in comment #1 (the one without the > bool) for the same reason as GCC. Interesting. Perhaps this is a common compiler bug? My reading of [expr.prim.id.general]p5 (http://eel.is/c++draft/expr.prim#id.general-5) and [over.over]p5 (http://eel.is/c++draft/over.over#5) suggests the code is intended to be valid. However, I'm no expert when it comes to the wording for overload resolution. >From [expr.prim.id.general]p5: > For an id-expression that denotes an overload set, overload resolution is > performed to select a unique function ([over.match], [over.over]). >From [over.over]p5: > ... Any given function template specialization F1 is eliminated if the set > contains a second function template specialization whose function template is > more specialized than the function template of F1 according to the partial > ordering rules of [temp.func.order]. After such eliminations, if any, there > shall remain exactly one selected function.
[Bug c++/116746] New: Explicit specializations of static variable templates are incorrectly given external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116746
Bug ID: 116746
Summary: Explicit specializations of static variable templates
are incorrectly given external linkage
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
As demonstrated by the following test case, GCC emits symbols with external
linkage for explicit specializations of variable templates declared with the
`static` storage class specifier. Such explicit specializations should be given
the same linkage as the primary template; internal linkage for this example.
This expectation is supported by the following sections of the C++ standard:
Per [temp.expl.spec]p4:
> An explicit specialization does not introduce a name ([basic.scope.scope]). …
Per [basic.link]p2:
> A name can have external linkage, module linkage, internal linkage, or no
> linkage, as determined by the rules below.
The test case consists of two source files, each of which declares a static
variable template named `ptr` and an associated explicit specialization of
`ptr`. When compiled and linked, link fails due to multiple definitions of
`ptr` (thus demonstrating that they were given external linkage).
Commenting out one or both of the explicit specializations suffices for the
program to link successfully and to run without assertion failures thus
demonstrating that the primary templates (and the specializations implicitly
instantiated from them) were given internal linkage.
Makefile:
```
all: main
clean:
rm -f main.o t.o main
main.o: main.cpp
g++ -c main.cpp
t.o: t.cpp
g++ -c t.cpp
main: main.o t.o
g++ main.o t.o -o main
```
main.cpp:
```
#include
static int x;
template static void* ptr = &x;
template <> void* ptr = &x;
extern void* f();
extern void* g();
int main() {
assert(ptr != f());
assert(ptr != g());
}
```
t.cpp:
```
static int x;
template static void* ptr = &x;
template <> void* ptr = &x;
void* f() {
return ptr;
}
void* g() {
return ptr;
}
```
An example build and invocation follows:
```
$ make
g++ -c main.cpp
g++ -c t.cpp
g++ main.o t.o -o main
ld: t.o:(.data+0x0): multiple definition of `ptr'; main.o:(.data+0x0):
first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:9: main] Error 1
```
This appears to be a common compiler bug as both Clang and MSVC exhibit similar
behavior as can be observed at https://godbolt.org/z/fzsdTG9rM. (Unfortunately,
that link won't demonstrate MSVC behavior currently due to a timeout issue
tracked at https://github.com/compiler-explorer/compiler-explorer/issues/6742).
A Clang bug report can be found at
https://github.com/llvm/llvm-project/issues/35211 and a MSVC bug report is
available at
https://developercommunity.visualstudio.com/t/Explicit-specializations-of-static-varia/10746502.
Note that the C++ standard does not permit an explicit specialization to be
declared with the static storage class specifier and it is therefore not
possible to explicitly declare that the explicit specializations have internal
linkage. Per [temp.expl.spec]p2:
> The declaration in an explicit-specialization shall not be an
> export-declaration. An explicit specialization shall not use a
> storage-class-specifier ([dcl.stc]) other than thread_local.
[Bug c/111884] [13/14 Regression] unsigned char no longer aliases anything under -std=c2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884 --- Comment #4 from Tom Honermann --- (In reply to Marek Polacek from comment #3) > Thanks, I can test Thank you. That change looks right. My apologies for introducing the regression.
[Bug c++/115658] char16_t and char32_t aliasing is conserative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #2 from Tom Honermann --- I think the prior comments regarding the aliasing sets refer to portions of c_common_get_alias_set() in gcc/gcc/c-family/c-common.cc, specifically the lines at https://github.com/gcc-mirror/gcc/blob/629257bcb81434117f1e9c68479032563176dc0c/gcc/c-family/c-common.cc#L3892-L3895. I think the alias sets are right; they are consistent with what the C++ standard states in [basic.lval]p11 (http://eel.is/c++draft/basic.lval#11). > So maybe we really should keep on treating them the same. and maybe change char8_t back to similar as unsigned char ... I don't think that should be necessary. P0482R6 was explicit in its intent that char8_t not be an aliasing type (http://wg21.link/p0482r6#proposal).
[Bug c++/115658] char16_t and char32_t aliasing is conserative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658
--- Comment #3 from Tom Honermann ---
In retrospect, I think I misunderstood Andrew's motivation for filing this
issue.
There is a difference of behavior between gcc and clang with regard to aliasing
of `char16_t` and `char32_t` with respect to other types. This is illustrated
by the following example as demonstrated at
https://www.godbolt.org/z/PsMsPMa73.
Please note that (at least) `-O2` is necessary to reliably demonstrate
differences in behavior. Additionally, the use of `-fshort-wchar` to influence
the size of `wchar_t` affects behavior.
```
template
U f(T *p, U *q) {
*p = 1;
U u = *q;
*p = 2;
return u;
}
template wchar_t f(char16_t*, wchar_t*);
template unsigned short f(char16_t*, unsigned short*);
template wchar_t f(char32_t*, wchar_t*);
template unsigned int f(char32_t*, unsigned int*);
```
The test case exercises dead store elimination in the presence of aliasing
types. If `T` may alias `U`, then the write of `1` to `*p` is observable by
`*q`, but may otherwise be eliminated due to the later write of `2` to `*p`.
For Clang, there is no aliasing between any of these types and the store of `1`
to `*p` is always eliminated.
For MSVC, it appears that either dead store elimination is not performed at
all, or aliasing is permitted across all of these types (even when the size
differs).
For gcc with `-fshort-wchar`, there appear to be two alias sets:
- `wchar_t`, `char16_t`, and `unsigned short`.
- `char32_t` and `unsigned int`.
For gcc without `-fshort-wchar`, there are also two alias sets, but they are
not symmetric in the presence of that option. Note that `char32_t` never
aliases with `wchar_t` even when they have the same size. This asymmetry is
explainable in consideration of compatibility with MSVC (where `wchar_t` is
always 16-bit).
- `char16_t` and `unsigned short`.
- `char32_t` and `unsigned int`.
Adding the following explicit template instantiations demonstrates that all of
gcc, clang, and MSVC permit aliasing between the set of `char`, `unsigned
char`, and `char8_t` (because `char` and `unsigned char` are permitted to alias
all types). https://www.godbolt.org/z/Pjxb661Y7.
```
template char f(char8_t*, char*);
template unsigned char f(char8_t*, unsigned char*);
```
To reiterate, I think the current gcc behavior is correct and defensible given
two goals:
- A desire to match MSVC behavior in the limited context of a 16-bit `wchar_t`
type.
- A desire to match C behavior with respect to `char16_t` and `char32_t`
aliasing the underlying types of `uint_least16_t` and `uint_least32_t` (the
former are typedefs in C).
[Bug objc++/119146] New: Documentation missing for the OBJCPLUS_INCLUDE_PATH environment variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119146 Bug ID: 119146 Summary: Documentation missing for the OBJCPLUS_INCLUDE_PATH environment variable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net Target Milestone: --- GCC's environment variable documentation (https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html#index-CPATH) is missing an entry for the `OBJCPLUS_INCLUDE_PATH` environment variable. The documentation source actually has an entry for this environment variable, but it is commented out (https://github.com/gcc-mirror/gcc/blob/d2b022e38a778d64350f4d4236a2c8a36e0e621c/gcc/doc/cppenv.texi#L17-L18). ``` gcc/gcc/doc/cppenv.texi: 17 @c Commented out until ObjC++ is part of GCC: 18 @c @itemx OBJCPLUS_INCLUDE_PATH ``` GCC has implemented support for `OBJCPLUS_INCLUDE_PATH` since at least 2003 (https://github.com/gcc-mirror/gcc/blob/d2b022e38a778d64350f4d4236a2c8a36e0e621c/gcc/incpath.cc#L496). I don't know when Objective C++ was officially deemed part of GCC, but I think it was a long time ago now and that the comment above is quite stale.
[Bug c++/119497] Improve diagnostic for failed assert(expr) in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119497 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #10 from Tom Honermann --- Improvements here would likely benefit from the availability of features proposed in P2758 (https://wg21.link/p2758; Emitting messages at compile time). P3290 (https://wg21.link/p3290; Integrating Existing Assertions with Contracts) is applicable as well.
