[Bug c++/115114] New: aggregate initialization with parens fails when there is a base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115114
Bug ID: 115114
Summary: aggregate initialization with parens fails when there
is a base class
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
I believe the following is valid C++20:
struct get_answer {};
template
struct with : Query {
Value value;
};
int main() {
with w1{get_answer(), 42}; // works
with w2(get_answer(), 42); // fails
}
clang and msvc accept this code. gcc-trunk rejects it. See
https://godbolt.org/z/KvGjn47f9.
If I change the definition of the `with` class template to the following, the
code compiles:
template
struct with {
Query query;
Value value;
};
[Bug c++/114138] New: [c++2b] ICE on valid code using `auto(expr)` DECAY-COPY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114138
Bug ID: 114138
Summary: [c++2b] ICE on valid code using `auto(expr)`
DECAY-COPY
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile the following with -c++=2b:
```
namespace std {
template
T&& declval() noexcept requires true;
template
void declval() noexcept;
namespace detail {
struct none_such;
template
using none_such_t = none_such;
template
extern const none_such_t _getter_for;
template
using _decay_t = decltype(auto(declval()));
static_assert(__is_same_as(_decay_t, void));
}
template
using _result_of_t = decltype(Fn(declval()...));
template
using tuple_element_t =
_result_of_t>, char(*)[I+1],
Tuple>;
template
struct pair {
First first;
Second second;
};
template
inline constexpr bool _is_pair = false;
template
inline constexpr bool _is_pair> = true;
template
concept Pair = _is_pair()))>;
template
requires (I <= 1)
decltype(auto) get(P&& p) noexcept {
if constexpr (I == 0) {
return (static_cast(p).first);
} else {
return (static_cast(p).second);
}
}
namespace detail {
inline constexpr auto _pair_getter =
[](char(*)[J], Pair&& p) noexcept ->
decltype(auto) {
return std::get(static_cast(p));
};
template
inline constexpr auto _getter_for> = _pair_getter;
}
}
int main() {
static_assert(__is_same_as(int&, std::tuple_element_t<0, std::pair&>));
static_assert(__is_same_as(float&&, std::tuple_element_t<1, std::pair&&>));
}
```
Result:
```
: In substitution of 'template using
std::tuple_element_t = std::_result_of_t<_getter_for()))>, char (*)[(I + 1)], Tuple> [with unsigned int I =
0; Tuple = std::pair&]':
:71:82: required from here
71 | static_assert(__is_same_as(int&, std::tuple_element_t<0,
std::pair&>));
|
^
:21:31: internal compiler error: in tsubst, at cp/pt.cc:16367
21 | using _decay_t = decltype(auto(declval()));
| ^~
0x265412c internal_error(char const*, ...)
???:0
0xa548c3 fancy_abort(char const*, int, char const*)
???:0
0xc99307 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9f3c9 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9f3c9 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xc98a19 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc80873 instantiate_template(tree_node*, tree_node*, int)
???:0
0xc9a0fc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc973cc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0xcd370f finish_template_type(tree_node*, tree_node*, int)
???:0
0xc577da c_parse_file()
???:0
0xdaba19 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
```
See https://godbolt.org/z/r13Yff5bM
[Bug c++/111018] New: lexical interpretation of friendship rules depends on whether the friend function has a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111018
Bug ID: 111018
Summary: lexical interpretation of friendship rules depends on
whether the friend function has a definition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Starting in gcc 12, transitive friendship is extended to friend functions that
are defined lexically within the body of the friend class. E.g.:
struct S;
struct T {
friend struct S;
private:
template
static void foo(T) {}
};
struct S {
template
friend auto bar(Self s) -> decltype(::T::foo(s)) { // (1)
return ::T::foo(s);
}
};
Prior to gcc-12, the commented line would have been rejected, but now it is
accepted. Great, it brings gcc in line with clang and is arguably more
sensible.
HOWEVER, it does NOT work if the friend function is merely declared but not
defined. For instance, this is still an error:
struct S;
struct T {
friend struct S;
private:
template
static void foo(T) {}
};
struct S {
template
friend auto bar(Self s) -> decltype(::T::foo(s)); // NO FN DEFINITION
};
int main() {
S s;
using T = decltype(bar(s)); // ERROR: T::foo is private
}
This is very confusing and inconsistent behavior.
See: https://godbolt.org/z/WT9P37Wba
[Bug c++/110681] New: bogus warning -Wreturn-type for lambda in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110681 Bug ID: 110681 Summary: bogus warning -Wreturn-type for lambda in tparam list Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- The following valid C++20 code causes gcc trunk to erroneously warn about a missing return statement. template constexpr auto y = X; template using C = decltype(y<>); using D = C; : In substitution of 'template using C = decltype (y< >) [with T = int]': :27:18: required from here :21:22: warning: no return statement in function returning non-void [-Wreturn-type] 21 | template | ^~~~ Compiler returned: 0
[Bug c++/110680] New: erroneous error "non-template type 'C' used as a template"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110680
Bug ID: 110680
Summary: erroneous error "non-template type 'C' used as a
template"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following valid C++20 is rejected by gcc trunk:
template
struct S {
auto f() { return X; }
};
template
using C = decltype(S().f());
using D = C;
:29:16: error: non-template type 'C' used as a template
29 | using D = C;
|^
Compiler returned: 1
https://godbolt.org/z/b3eY8fWTv
[Bug c++/110552] New: ICE on valid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
Bug ID: 110552
Summary: ICE on valid code in maybe_instantiate_noexcept
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Created attachment 55469
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55469=edit
self-contained source file
Compile the attached source with -std=c++20. Result:
/home/eniebler/hello_world.cpp: In substitution of ‘template requires tag_invocable constexpr
stdexec::__tag_invoke::tag_invoke_result_t stdexec::__env::get_env_t::operator()(const _EnvProvider&) const
[with _EnvProvider = stdexec::__basic_sender<:: >]’:
/home/eniebler/hello_world.cpp:2221:16: required from here
/home/eniebler/hello_world.cpp:1465:59: internal compiler error: in
maybe_instantiate_noexcept, at cp/pt.cc:26753
1465 | requires(_Tag __tag, _Args&&... __args) { tag_invoke((_Tag&&)
__tag, (_Args&&) __args...); };
|
~~^
0xace10a maybe_instantiate_noexcept(tree_node*, int)
../../gcc/cp/pt.cc:26753
0x96272f mark_used(tree_node*, int)
../../gcc/cp/decl2.cc:5720
0x864a35 build_over_call
../../gcc/cp/call.cc:10394
0x867e0b build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.cc:5038
0xb304ff finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2924
0xacc4e5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21338
0xabb964 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19888
0x8c3193 tsubst_valid_expression_requirement
../../gcc/cp/constraint.cc:2002
0x8cc3c0 tsubst_simple_requirement
../../gcc/cp/constraint.cc:2036
0x8cc3c0 tsubst_requirement
../../gcc/cp/constraint.cc:2233
0x8cc3c0 tsubst_requires_expr
../../gcc/cp/constraint.cc:2363
0x8cc8aa tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:2382
0xac96c7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21749
0xabb964 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19888
0x8cde63 satisfy_atom
../../gcc/cp/constraint.cc:3041
0x8cde63 satisfy_constraint_r
../../gcc/cp/constraint.cc:3106
0x8ce723 satisfy_normalized_constraints
../../gcc/cp/constraint.cc:3131
0x8caefd satisfy_declaration_constraints
../../gcc/cp/constraint.cc:3352
0x8caefd constraint_satisfaction_value
../../gcc/cp/constraint.cc:3373
0x8ce78f constraints_satisfied_p(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:3410
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
See https://godbolt.org/z/1511TYvch for a demo of the bug on compiler explorer.
[Bug c++/110536] New: Bogus -Wstringop-overflow warning in std::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110536
Bug ID: 110536
Summary: Bogus -Wstringop-overflow warning in std::transform
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile the following with -O3 -std=c++17 -Wall
<<<<<
#include
#include
template
std::vector
make_type_param_vector(std::initializer_list const& init_list) {
// std::vector input{init_list}; //uncomment to remove warning
std::vector vec(init_list.size());
std::transform(std::cbegin(init_list), std::cend(init_list), std::begin(vec),
[](auto const& e) {
if constexpr (std::is_unsigned_v) { return
static_cast(std::abs(e)); }
return static_cast(e);
});
return vec;
}
template
void validate_A() {
auto const input_column_valid_a = make_type_param_vector({1, 0});
auto const input_column_valid_b = make_type_param_vector({0, 0});
auto const input_column_valid_c = make_type_param_vector({15, 16});
}
int main() {
validate_A();
validate_A();
validate_A();
validate_A();
validate_A();
validate_A();
validate_A();
validate_A();
validate_A();
}
<<<<<:1:
In function '_OIter std::transform(_IIter, _IIter, _OIter, _UnaryOperation)
[with _IIter = const int*; _OIter = __gnu_cxx::__normal_iterator > >; _UnaryOperation =
make_type_param_vector(const
std::initializer_list&)::]',
inlined from 'std::vector make_type_param_vector(const
std::initializer_list&) [with TypeParam = unsigned char; T = int]' at
:10:17:
/opt/compiler-explorer/gcc-trunk-20230703/include/c++/14.0.0/bits/stl_algo.h:4216:19:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
4216 | *__result = __unary_op(*__first);
| ~~^~
Demo:
https://godbolt.org/z/PKqfjr9cb
[Bug libstdc++/110507] New: cannot initialize immovable type in a std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110507
Bug ID: 110507
Summary: cannot initialize immovable type in a std::tuple
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following should work since C++17, when C++ got guaranteed copy elision.
#include
struct immovable {
immovable() = default;
immovable(immovable&&) = delete;
};
struct init_immovable {
operator immovable() const { return {}; }
};
int main() {
std::tuple m{init_immovable{}};
}
result:
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple: In
instantiation of 'constexpr std::_Head_base<_Idx, _Head,
true>::_Head_base(_UHead&&) [with _UHead = init_immovable; long unsigned int
_Idx = 0; _Head = immovable]':
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple:514:38:
required from here
:13:43: in 'constexpr' expansion of
'm.std::tuple::tuple(init_immovable())'
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple:891:54: in
'constexpr' expansion of '((std::_Tuple_impl<0,
immovable>*)this)->std::_Tuple_impl<0,
immovable>::_Tuple_impl((* & std::forward((* &
__elements#0'
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple:92:11:
error: use of deleted function 'immovable::immovable(immovable&&)'
92 | : _M_head_impl(std::forward<_UHead>(__h)) { }
| ^~~
:5:3: note: declared here
5 | immovable(immovable&&) = delete;
| ^
https://godbolt.org/z/nfd1zdcqs
[Bug c++/110441] New: c++17 deferred materialization of temporaries fails when calling class static with member syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
Bug ID: 110441
Summary: c++17 deferred materialization of temporaries fails
when calling class static with member syntax
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
struct immovable {
immovable() = default;
immovable(immovable &&) = delete;
};
struct S {
static immovable f() {
return {};
}
};
immovable g() {
return S().f();
}
compile with -std=c++17. Result:
: In function 'immovable g()':
:14:15: error: use of deleted function
'immovable::immovable(immovable&&)'
14 | return S().f();
| ~^~
:4:3: note: declared here
4 | immovable(immovable &&) = delete;
| ^
https://godbolt.org/z/Y1h9bPrf3
[Bug c++/109790] internal compiler error in write_member_name, at cp/mangle.cc:2992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109790 --- Comment #1 from Eric Niebler --- Possible dupe of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100632
[Bug c++/109790] New: internal compiler error in write_member_name, at cp/mangle.cc:2992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109790
Bug ID: 109790
Summary: internal compiler error in write_member_name, at
cp/mangle.cc:2992
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Created attachment 55032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55032=edit
the result of -freport-bug
Compile the attached test_when_all.i.cpp with:
g++ -std=c++20 -fext-numeric-literals -Wno-non-template-friend \
test_when_all.i.cpp
Result:
In file included from
/home/eniebler/Code/stdexec/include/stdexec/execution.hpp:35,
from
/home/eniebler/Code/stdexec/test/stdexec/algos/adaptors/test_when_all.cpp:18:
/home/eniebler/Code/stdexec/include/stdexec/__detail/__tuple.hpp: In
instantiation of ‘constexpr stdexec::__tup::__tuple_for<_Ts ...>
stdexec::__tup::__make_tuple_fn::operator()(_Ts ...) const [with _Ts =
{C_A_T_C_HT_E_S_T24()::}]’:
/home/eniebler/Code/stdexec/include/stdexec/__detail/__tuple.hpp:284:37:
required from here
/home/eniebler/Code/stdexec/include/stdexec/__detail/__tuple.hpp:284:37:
internal compiler error: in write_member_name, at cp/mangle.cc:2992
284 | constexpr __tuple_for<_Ts...> operator()(_Ts... __ts) const
| ^~~~
0x9acf33 write_member_name
../../gcc/cp/mangle.cc:2992
0x9ace8f write_member_name
../../gcc/cp/mangle.cc:2999
0x9ad8ce write_expression
../../gcc/cp/mangle.cc:3668
0x9adecc write_expression
../../gcc/cp/mangle.cc:3592
0x9b290c write_type
../../gcc/cp/mangle.cc:2489
0x9b198c write_template_args
../../gcc/cp/mangle.cc:2966
0x9b7e2f write_nested_name
../../gcc/cp/mangle.cc:1154
0x9b26de write_class_enum_type
../../gcc/cp/mangle.cc:2937
0x9b26de write_type
../../gcc/cp/mangle.cc:2362
0x9b6739 write_bare_function_type
../../gcc/cp/mangle.cc:2856
0x9b699b write_mangled_name
../../gcc/cp/mangle.cc:799
0x9b8827 mangle_decl_string
../../gcc/cp/mangle.cc:4143
0x9b8ac8 get_mangled_id
../../gcc/cp/mangle.cc:4164
0x9b8ac8 mangle_decl(tree_node*)
../../gcc/cp/mangle.cc:4202
0x15934b5 decl_assembler_name(tree_node*)
../../gcc/tree.cc:715
0x15c6d59 assign_assembler_name_if_needed(tree_node*)
../../gcc/tree.cc:830
0xd126f1 cgraph_node::analyze()
../../gcc/cgraphunit.cc:677
0xd15f7a analyze_functions
../../gcc/cgraphunit.cc:1247
0xd170ed symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2554
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/109782] New: erroneous error "'auto' parameter not permitted in this context" for generic lambda in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109782
Bug ID: 109782
Summary: erroneous error "'auto' parameter not permitted in
this context" for generic lambda in tparam list
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template
struct C {};
...compiled with `-std=c++20` results in:
:1:23: error: 'auto' parameter not permitted in this context
1 | template
| ^~~~
Compiler returned: 1
[Bug c++/109781] New: erroneous error "lambda-expression in template parameter type" for tparam lambda returning a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109781
Bug ID: 109781
Summary: erroneous error "lambda-expression in template
parameter type" for tparam lambda returning a lambda
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template
struct C {};
... on trunk with `-std=c++20` results in:
: In lambda function:
:1:31: error: lambda-expression in template parameter type
1 | template
| ^
Compiler returned: 1
I don't know of a reason why this code should be rejected.
[Bug c++/105667] [C++20] lambas in template argument sometimes causes an ICE (seg fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105667
Eric Niebler changed:
What|Removed |Added
CC||eric.niebler at gmail dot com
--- Comment #7 from Eric Niebler ---
Another, even shorter repro:
template (B){}>
struct C {
using D = void;
};
template
using E = C<>::D;
using F = E<>;
[Bug c++/109754] New: [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109754
Bug ID: 109754
Summary: [ICE] internal compiler error: in
coerce_template_parms, at cp/pt.cc:9183
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Created attachment 55012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55012=edit
result of -freport-bug including preprocessed source
similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475, but not using
coroutines
Repro: compile attached code with -std=c++20
Result:
In file included from test.cpp:1:
stdexec/include/stdexec/__detail/__meta.hpp: In substitution of ‘template using __minvoke = stdexec::__meval<_Fn::template __f,
_Args ...> [with _Fn =
stdexec::__mexpand, const char*>(int&&,
stdexec::__tup::__coerce&&, const char*&&)
const > >; _Args = {stdexec::__msize}]’:
stdexec/include/stdexec/__detail/__meta.hpp:431:9: required by substitution
of ‘template using __mapply =
stdexec::__minvoke, _Fn> [with _Fn =
stdexec::__msize; _List =
stdexec::__tuple, const char*>(int&&,
stdexec::__tup::__coerce&&, const char*&&)
const >]’
stdexec/include/stdexec/__detail/__tuple.hpp:491:47: required from ‘const
std::size_t
stdexec::tuple_size_v, const char*>(int&&,
stdexec::__tup::__coerce&&, const char*&&)
const > >’
test.cpp:22:26: required from here
stdexec/include/stdexec/__detail/__meta.hpp:233:9: internal compiler error: in
coerce_template_parms, at cp/pt.cc:9183
233 | using __minvoke = __meval<_Fn::template __f, _Args...>;
| ^
0x6623b1 coerce_template_parms
../../src/gcc/cp/pt.cc:9183
0x818feb instantiate_alias_template
../../src/gcc/cp/pt.cc:21719
0x818feb tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15607
0x81c344 tsubst_decl
../../src/gcc/cp/pt.cc:14952
0x81815a instantiate_template_1
../../src/gcc/cp/pt.cc:21643
0x81908e instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.cc:21702
0x81908e instantiate_alias_template
../../src/gcc/cp/pt.cc:21740
0x81908e tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15607
0x81c344 tsubst_decl
../../src/gcc/cp/pt.cc:14952
0x81815a instantiate_template_1
../../src/gcc/cp/pt.cc:21643
0x81908e instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.cc:21702
0x81908e instantiate_alias_template
../../src/gcc/cp/pt.cc:21740
0x81908e tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15607
0x825bad tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:13517
0x8108fe tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:20055
0x8200e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:19491
0x81fe84 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x81fe84 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.cc:26653
0x7313c1 maybe_instantiate_decl(tree_node*)
../../src/gcc/cp/decl2.cc:5627
0x7375ef maybe_instantiate_decl(tree_node*)
../../src/gcc/cp/decl2.cc:5614
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c++/108848] New: Accessing class static member of non-dependent expression using member syntax in dependent context is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848
Bug ID: 108848
Summary: Accessing class static member of non-dependent
expression using member syntax in dependent context is
rejected
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Clang accepts the following, gcc thinks the expression in the line marked
"HERE" should be `tag.template smbr`.
template
struct tag_t {
template
static constexpr const Sig* smbr = nullptr;
int i = 0;
};
template
inline constexpr tag_t tag {};
// This is OK
using X = decltype(tag.smbr);
template
struct S {
// This is incorrectly rejected by gcc
using Y = decltype(tag.smbr);
// This is OK
using Z = decltype(tag_t::smbr);
};
https://godbolt.org/z/9GoPYTYa1
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #5 from Eric Niebler --- > Github's poor life choices should not be our problem ;-) I thought you'd say that. :-) > If clang-8 doesn't ship and doesn't work with GCC's > , I would interpret that as you can't test with > clang-8. Yeah, except I'm not trying to test . I'm just trying to include , which includes and hard-errors. In fact, what I'm _really_ trying to do is include , which includes , which includes , which includes . All roads, it seems, lead to .
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #3 from Eric Niebler --- It seems like GitHub actions uses the latest libstdc++ by default when testing even with old (e.g., clang-4) toolsets. That seems busted, but regardless, this is now breaking _all_ my Linux clang tests for anything less than clang-9, which is unfortunate.
[Bug libstdc++/97876] New: stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 Bug ID: 97876 Summary: stop_token header doesn't compile on clang-8 with -std=c++20 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Compiling header with clang-8 in C++20 mode results in this: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/condition_variable:50: /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:404:7: error: default member initializer for '_M_ptr' needed within definition of enclosing class 'stop_token' outside of member functions _Stop_state_ref() = default; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:478:21: note: in evaluation of exception specification for 'std::stop_token::_Stop_state_ref::_Stop_state_ref' needed here _Stop_state_ref _M_state; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:58:5: note: in evaluation of exception specification for 'std::stop_token::stop_token' needed here stop_token() noexcept = default; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:475:22: note: default member initializer declared here _Stop_state_t* _M_ptr = nullptr; ^ 1 error generated.
[Bug c++/94827] New: [ICE] [regression] crash on requires clause in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827
Bug ID: 94827
Summary: [ICE] [regression] crash on requires clause in tparam
list
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Try the following code with -std=c++2a
template
void foo(T) {}
The result:
:20:44: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in map_arguments, at cp/constraint.cc:553
20 | bool = requires { requires (sizeof(T)==0); } >
|^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
This compiles with gcc-9 with -std=c++2a -fconcepts, so this is a regression.
[Bug c++/94808] New: [ICE] [Regression] Segfault during diagnostics from concept check failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94808
Bug ID: 94808
Summary: [ICE] [Regression] Segfault during diagnostics from
concept check failure
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Created attachment 48385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48385=edit
Unreduced, preprocessed source
This problem reproduces on trunk built today (4/27/2020). Compile the attached
preprocessed source with the attached script (flags: -std=gnu++2a).
I expect to see a diagnostic since the program should not satisfy the concept
checks. Instead, during diagnostic reporting I see the following:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/test/P0443_test.cpp: In member function
‘virtual void P0443_connect_with_executor_Test::TestBody()’:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/test/P0443_test.cpp:81:53: error: no match
for call to ‘(const unifex::_connect::_fn) ({anonymous}::inline_executor,
P0443_connect_with_executor_Test::TestBody()::_receiver)’
81 | auto op = connect(inline_executor{}, _receiver{});
| ^
In file included from /Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/executor_concepts.hpp:174,
from /Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/test/P0443_test.cpp:17:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/sender_concepts.hpp:224:10:
note: candidate: ‘template requires
(receiver) && ((sender)
&& (tag_invocable))
unifex::_tag_invoke::tag_invoke_result_t unifex::_connect::_fn::operator()(Sender&&, Receiver&&) const’
224 | auto operator()(Sender&& s, Receiver&& r) const
| ^~~~
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/sender_concepts.hpp:224:10:
note: template argument deduction/substitution failed:
In file included from /Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/executor_concepts.hpp:20,
from /Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/test/P0443_test.cpp:17:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/tag_invoke.hpp: In
substitution of ‘template using tag_invoke_result_t
= decltype (unifex::_tag_invoke::tag_invoke(static_cast(nullptr)(), static_cast(nullptr)()...))
[with CPO = unifex::_connect::_fn; Args = {{anonymous}::inline_executor,
P0443_connect_with_executor_Test::TestBody()::_receiver}]’:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/sender_concepts.hpp:224:10:
required by substitution of ‘template requires
(receiver) && ((sender)
&& (tag_invocable))
unifex::_tag_invoke::tag_invoke_result_t unifex::_connect::_fn::operator()(Sender&&, Receiver&&) const [with
Sender = {anonymous}::inline_executor; Receiver =
P0443_connect_with_executor_Test::TestBody()::_receiver]’
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/test/P0443_test.cpp:81:53: required from
here
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/tag_invoke.hpp:39:19:
error: too many arguments to function ‘void unifex::_tag_invoke::tag_invoke()’
39 | tag_invoke(UNIFEX_DECLVAL(CPO && ), UNIFEX_DECLVAL(Args &&
)...));
|
~~^~~~
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/tag_invoke.hpp:26:10:
note: declared here
26 | void tag_invoke();
| ^~
In file included from /Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/executor_concepts.hpp:174,
from /Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/test/P0443_test.cpp:17:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/sender_concepts.hpp:233:10:
note: candidate: ‘template requires
(receiver) && !((sender)
&& (tag_invocable)) &&
((sender) && (_has_member_connect))
unifex::_connect::_member_connect_result_t
unifex::_connect::_fn::operator()(Sender&&, Receiver&&) const’
233 | auto operator()(Sender&& s, Receiver&& r) const
| ^~~~
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unifex/sender_concepts.hpp:233:10:
note: template argument deduction/substitution failed:
/Users/eniebler/Dropbox
(Facebook)/home/Code/Code/libunifex/source/../include/unife
[Bug c++/70790] Can't mangle noexcept expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70790 --- Comment #1 from Eric Niebler --- Still present on trunk, four years later.
[Bug libstdc++/93936] New: [ranges] std::ranges::split_view<...>::_OuterIter<...>::__current() is private within this context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93936
Bug ID: 93936
Summary: [ranges]
std::ranges::split_view<...>::_OuterIter<...>::__curre
nt() is private within this context
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following program fails to compile with -std=c++2a on gcc-trunk:
#include
#include
#include
#include
#include
#include
inline constexpr auto as_string = [](std::ranges::view auto rng) {
auto in = rng | std::views::common;
return std::string(in.begin(), in.end());
};
int main() {
namespace views = std::views;
std::string str = "Now is the time for all good men to come to the aid of
their county.";
auto rng = str | views::split(' ') | views::transform(as_string) |
views::common;
std::vector words(rng.begin(), rng.end());
std::ranges::copy(words,
std::ostream_iterator{std::cout,","});
}
The error is:
/opt/compiler-explorer/gcc-trunk-20200225/include/c++/10.0.1/ranges:2828:31:
error: 'constexpr auto& std::ranges::split_view<_Vp,
_Pattern>::_OuterIter<_Const>::__current() const [with bool _Const = true; _Vp
= std::ranges::ref_view >; _Pattern =
std::ranges::single_view]' is private within this context
2828 |{ return __x._M_i.__current() == __y._M_i.__current(); }
| ~~^~
Obligatory godbolt link: https://godbolt.org/z/B4tZPx
[Bug c++/93895] ICE (segmentation fault) in use of __is_constructible intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895
--- Comment #1 from Eric Niebler ---
Here is the error:
repro.cpp.i: In instantiation of ‘bool bf::{anonymous}::bb, false> >’:
repro.cpp.i:158:67: required from ‘df::operator Container() [with
Container = view_facade,
false>::outer_cursor::inner_view, bh>; bool dk = true; dd =
chunk_view_, false>; bg de = bh]’
repro.cpp.i:206:1: required from ‘chunk_view_::outer_cursor::inner_view chunk_view_::outer_cursor::q()
[with cd = debug_input_view]’
repro.cpp.i:102:5: required from ‘auto ci::q(ck) [with ck =
chunk_view_, false>::outer_cursor]’
repro.cpp.i:123:6: required from ‘auto cf::operator*() [with ck =
chunk_view_, false>::outer_cursor]’
repro.cpp.i:57:1: required from ‘void cm::is_iterator(bw) requires t
[with bw = cf, false>::outer_cursor>]’
repro.cpp.i:129:12: required from ‘auto cm::cp::operator()(bx) requires
co [with bx = chunk_view >]’
repro.cpp.i:148:49: required from here
repro.cpp.i:40:50: internal compiler error: Segmentation fault: 11
40 | template bool bb = __is_constructible(ah,
an...);
|
^
[Bug c++/93895] New: ICE (segmentation fault) in use of __is_constructible intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895 Bug ID: 93895 Summary: ICE (segmentation fault) in use of __is_constructible intrinsic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Created attachment 47892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47892=edit result of creduce on the error Happens with trunk. Compile the attached repro.cpp.i with: g++ -std=c++2a -xc++ -c repro.cpp.i The attached file is the result of creduce which sadly made the code invalid, but the original ICE happened on valid code.
[Bug c++/93741] New: [10 regression] ICE in incomplete concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93741
Bug ID: 93741
Summary: [10 regression] ICE in incomplete concept definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following (very invalid) code fragment causes gcc-trunk to ICE:
template struct a { b({
concept c =
[Bug c++/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667 --- Comment #3 from Eric Niebler --- > Is this a duplicate / variant of > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516? Bug 93516 is not triggered by [[no_unique_addresss]] and the ICE is not on the same line. That's why I created a new issue.
[Bug c++/93667] New: [10 regression] ICE in esra with nested [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
Bug ID: 93667
Summary: [10 regression] ICE in esra with nested
[[no_unique_address]] field
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile with: -std=c++2a -O2
struct a {};
struct b { [[no_unique_address]] a aq; };
struct c {
int d;
[[no_unique_address]] b e;
};
c f() {return {};}
void g() { f(); }
Result:
during GIMPLE pass: esra
repro.cpp.i: In function ‘void g()’:
repro.cpp.i:8:17: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2327
8 | void g() { f(); }
| ^
[Bug c++/92633] New: [concepts] constrained lambda with placehoder syntax getting wrong substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92633
Bug ID: 92633
Summary: [concepts] constrained lambda with placehoder syntax
getting wrong substitution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following code fails to compile with trunk with -std=c++2a
template
concept different_than = !__is_same_as(A, B);
template
auto diff(B) {
return [](different_than auto a) {};
}
int main() {
diff(42)("");
}
By the time the compiler evaluates the constraint, it seems to have forgotten
the context in which the constraint lives; that is, it no longer seems to know
what type B is.
I think the code should compile, and it does with clang-concepts:
https://godbolt.org/z/3QzhxS
[Bug c++/89068] New: Nested inline anonymous namespaces are erroneously reported as conflicting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068
Bug ID: 89068
Summary: Nested inline anonymous namespaces are erroneously
reported as conflicting
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following valid code is rejected by g++ -std=c++XY for any XY >= 11:
inline namespace {
inline namespace {}
}
inline namespace {}
The error message I get is:
:4:8: error: 'namespace { }' conflicts with a previous declaration
inline namespace {}
^
:1:8: note: previous declaration 'namespace { }'
inline namespace {
^
Compiler returned: 1
[Bug c++/86098] New: [concepts] canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86098
Bug ID: 86098
Summary: [concepts] canonical types differ for identical types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile with -std=c++2a -O3 -fconcepts
namespace std {
template class future;
template class promise;
}
template
T&& declval() requires true;
template
void declval();
template class T>
struct construct_deduced {
template
using deduced_t = decltype(T{declval()...});
template
requires requires {typename deduced_t;}
auto operator()(AN&&... an) const {
return T{(AN&&)an...};
}
};
template
concept bool Foo = true;
template
requires Foo>
std::future future_from(Out singleSender);
Result:
:26:29: internal compiler error: canonical types differ for identical
types '_Res' and 'T'
requires Foo>
^
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
See https://godbolt.org/g/4HkFdn
[Bug c++/84810] New: [concepts][c++20] constraints of lambdas with explicit template parameters are not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84810
Bug ID: 84810
Summary: [concepts][c++20] constraints of lambdas with explicit
template parameters are not checked
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following code declares a C++20 lambda with a constraint. The invocation of
the lambda should be ill-formed unless the constraint is satisfied; however,
gcc is accepting invalid code.
template constexpr bool is_int = false;
template <> constexpr bool is_int = true;
template
concept bool Int = is_int;
int main() {
auto x = [](T t) { return 42; };
auto y = x(42);
auto z = x(""); // should be ill-formed.
return z;
}
Compile with gcc trunk and `-fconcepts -std=gnu++2a`.
[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093
--- Comment #1 from Eric Niebler ---
Still happens on trunk, 2 years later:
template
concept bool True = true;
template
struct S {
friend bool operator==(S, int) requires True { return true; }
friend bool operator==(S, int) requires !True { return true; }
};
int main() {
S s;
}
:-(
[Bug c++/82507] New: [concepts] premature substitution into constraint of non-template member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82507
Bug ID: 82507
Summary: [concepts] premature substitution into constraint of
non-template member function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
According to Andrew Sutton, the following code should compile:
template
concept bool True = true;
template
concept bool HasType = requires { typename T::type; };
template
struct S {
void foo() requires HasType && True;
};
S s;
The failure of the HasType constraint should prevent substitution from
happening into True<>, avoiding a hard error. Instead, substitution happens
eagerly, leading to a hard error.
[Bug libstdc++/71187] declval() can be implemented without requiring a template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71187 --- Comment #3 from Eric Niebler --- I suppose, but I doubt it would matter much. add_rvalue_reference is not used nearly as frequently as declval (except in the current implementation of declval).
[Bug c++/80488] New: Erroneous error "lambda-expression in template argument"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80488
Bug ID: 80488
Summary: Erroneous error "lambda-expression in template
argument"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile with -std=gnu++1z:
template using x = void;
using Y = x<+[]{}>;
The above code creates a lambda and then applies unary operator +, forcing it
to decay to a function pointer. Since that's constexpr, it should be a valid
template argument.
clang-trunk accepts this code.
[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78231 Eric Niebler changed: What|Removed |Added CC||eric.niebler at gmail dot com --- Comment #6 from Eric Niebler --- Jonathan, the wording for std::reverse mentions iter_swap and doesn't seem to say whether it is called qualified or unqualified. AFAIK, it is the only algorithm that is required to use iter_swap. It seems to be a hold-over from a time before time. The requires clause says that *value must be swappable, but it doesn't *exactly* say that the call to iter_swap must resolve to the version in namespace std that does swap(*a,*b). Please forgive me if I'm misreading the standard.
[Bug c++/78003] [7 Regression] c++17: ICE in build_over_call, at cp/call.c:7847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78003 Eric Niebler changed: What|Removed |Added CC||eric.niebler at gmail dot com --- Comment #4 from Eric Niebler --- *** Bug 78137 has been marked as a duplicate of this bug. ***
[Bug c++/78137] [C++1z] braced initializer in defaulted function argument causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78137 Eric Niebler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Eric Niebler --- Didn't see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78003. FWIW, this repro is simpler. *** This bug has been marked as a duplicate of bug 78003 ***
[Bug c++/78137] New: [C++1z] braced initializer in defaulted function argument causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78137
Bug ID: 78137
Summary: [C++1z] braced initializer in defaulted function
argument causes ICE
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
With -std=gnu++1z, the following code ICEs the compiler:
```
struct S {};
template
void foo(T t = {}) {}
int main() {
foo();
}
```
Result:
test.cpp: In function ‘int main()’:
test.cpp:6:7: internal compiler error: in build_over_call, at cp/call.c:7847
foo();
^
The same code compiles successfully with -std=gnu++14.
[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537 --- Comment #12 from Eric Niebler --- Likewise
[Bug libstdc++/71187] New: declval() can be implemented without requiring a template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71187
Bug ID: 71187
Summary: declval() can be implemented without requiring a
template instantiation
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
declval gets used *everywhere*. It doesn't need to instantiate a template.
Rather than:
template
inline typename add_rvalue_reference<_Tp>::type
declval() noexcept
{
static_assert(__declval_protector<_Tp>::__stop,
"declval() must not be used!");
return __declval_protector<_Tp>::__delegate();
}
declval can be defined as:
template
_Up
__declval(int);
template
_Tp
__declval(long);
template
auto declval() noexcept -> decltype(__declval<_Tp>(0))
{
static_assert(__declval_protector<_Tp>::__stop,
"declval() must not be used!");
return __declval_protector<_Tp>::__delegate();
}
In a large code base that makes heavy use of templates, this small change is a
measured 4% compile-time win (g++ (GCC) 5.x 20160302).
I think the as-if rule gives implementers enough latitude to make this change.
[Bug c++/71117] New: [6.1 regression] Overeager application of conversion to function pointer during overload resolution of call to function object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117
Bug ID: 71117
Summary: [6.1 regression] Overeager application of conversion
to function pointer during overload resolution of call
to function object
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Casey Carter recently posted this to the committee core- mailing list:
<<<<<<<<<<< BEGIN
It is a commonplace library technique to compose function objects, which are
often empty, by inheritance to take advantage of the Empty Base Optimization.
E.g., this program patterned on usage in range-v3 turns a function that accepts
objects into a function that accepts iterators that denote objects:
template T&& declval() noexcept;
template <class, class>
constexpr bool is_same = false;
template
constexpr bool is_same<T, T> = true;
template
struct indirected : F {
indirected(F f) : F(f) {}
template
auto operator()(I i) -> decltype(declval<F&>()(*i)) {
return static_cast<F&>(*this)(*i);
}
};
int main() {
auto f = [](auto rng) {
static_assert(is_same<decltype(rng), int>, "");
return 42;
};
indirected<decltype(f)> i(f);
static_assert(is_same<decltype(i(declval<int*>())), int>, "");
}
Unfortunately, when the adapted function object is an underconstrained
captureless generic lambda - as is the case in the example - composition by
inheritance is extremely fragile. Since the lambda is captureless, its closure
type has a member conversion operator that converts to a function pointer type
with deduced return type. An attempt to call the derived type's call operator
results in overload resolution instantiating the conversion operator's
declaration necessitating return type deduction from the base object's call
operator. When the base object's call operator is ill-formed for the particular
argument types - again as is the case in the example - the program is
ill-formed.
GCC 6 and trunk tell me this program is ill-formed:
casey@Semiregular:~/bugs$ ~/gcc/bin/g++ -std=c++14 repro.cpp
repro.cpp: In instantiation of ‘main()::<lambda(auto:1)> [with auto:1 = int*]’:
repro.cpp:17:25: required by substitution of ‘template
main()::<lambda(auto:1)>::operator decltype
(((main()::<lambda(auto:1)>)0u).operator()(static_cast()))
(*)(auto:1)() const [with auto:1 = int*]’
repro.cpp:22:53: required from here
repro.cpp:18:9: error: static assertion failed
static_assert(is_same<decltype(rng), int>, "");
^
older versions of GCC and all versions of Clang I've tried compile the program
without diagnostics. Since hiding of conversion operators is based on the
target types, and determining the target type of the problematic conversion
operator results in the aforementioned ill-formed return type deduction, there
seems to be no way to hide the problematic conversion operator.
>>>>>>>>>>>>>>>>>>>>>>>> END
To which Richard Smith replied:
<<<<<<<<<<<<<<<<<<<<<<<< BEGIN
template using id = T;
struct F {
template operator id<T(*)(T)>();
} f;
int n = f(0);
GCC accepts this and calls the conversion function template with T=int. Clang,
EDG, MSVC reject.
Per [over.call.object]/2, I think GCC is wrong per the current language
wording. A conversion function template does not qualify as a "non-explicit
conversion function declared in [F or base class thereof]" (because it is not a
conversion function), and nor does a specialization of one (because it is not
itself declared in F).
I also don't see any way the current wording would take us to
[temp.deduct.conv] for this case, nor how that wording would apply (since we
don't have a function type that's required as the result of the conversion).
Perhaps GCC is following the rules of [temp.deduct.call] in this case, treating
the (pointee type of the) result type of the conversion function as if it were
the function type of the callee?
In the abstract, GCC's approach to this situation seems superior -- it's able
to use a conversion to function pointer in many cases where other compilers
can't -- but I'm a little hesitant to suggest we adopt that approach since it
breaks examples like yours.
>>>>>>>>>>>>>>>>>>>>>>>>> END
[Bug c++/71116] New: Lambdas should not be literal types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71116
Bug ID: 71116
Summary: Lambdas should not be literal types
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
#include
template
void oops(Fn) {
static_assert(!std::is_literal_type::value, "oops");
}
int main() {
oops([]{});
}
Yields:
test.cpp: In instantiation of ‘void oops(Fn) [with Fn = main()::<lambda()>]’:
test.cpp:9:12: required from here
test.cpp:5:3: error: static assertion failed: oops
static_assert(!std::is_literal_type::value, "oops");
^
([expr.prim.lambda]/p3) "The type of the lambda-expression (which is also the
type of the closure object) is a unique, unnamed non-union class type — called
the closure type — whose properties are described below. This class type is
neither an aggregate (8.5.1) nor a literal type (3.9)."
[Bug c++/70790] New: Can't mangle noexcept expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70790
Bug ID: 70790
Summary: Can't mangle noexcept expressions
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
#include
template
void foo(T, typename std::enable_if<noexcept(T(std::declval())), int>::type)
{
}
int main() {
foo(0,0);
}
Results in:
Test.cpp: In instantiation of ‘void foo(T, typename std::enable_if())), int>::type) [with T = int; typename
std::enable_if())), int>::type = int]’:
Test.cpp:19:6: sorry, unimplemented: mangling noexcept_expr
void foo(T, typename std::enable_if<noexcept(T(std::declval())),
int>::type)
^
[Bug c++/68434] [concepts] ICE: same canonical type node for different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68434 Eric Niebler changed: What|Removed |Added CC||eric.niebler at gmail dot com --- Comment #1 from Eric Niebler --- Created attachment 36788 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36788=edit More complicated repro scenario I just his this problem, too. I'm attaching an additional unreduced test case, in case it helps.
[Bug c++/67148] New: [concepts] Failed concept check when indirecting through a constrained trait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67148
Bug ID: 67148
Summary: [concepts] Failed concept check when indirecting
through a constrained trait
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
I've reduced this as much as I can. Test case below. The two static asserts are
testing the same thing, AFAICT. One tests the Function concept directly, the
other tests it indirectly through a __function trait that has been constrained
with Function. The former succeeds while the latter fails. Somewhat mysterious.
namespace std
{
typedef unsigned int size_t;
typedef int ptrdiff_t;
typedef decltype(nullptr) nullptr_t;
templatetypename _Tp, _Tp... _Idx
struct integer_sequence
{
typedef _Tp value_type;
static constexpr size_t size() { return sizeof...(_Idx); }
};
template class T, T Value
struct integral_constant {
using type = integral_constant;
using value_type = T;
constexpr operator T() const { return Value; }
constexpr T operator()() const { return Value; }
static constexpr T value {Value};
};
template class T, T Value
constexpr T integral_constantT, Value::value;
using true_type = integral_constantbool, true;
using false_type = integral_constantbool, false;
template class T, class U
struct is_same : false_type {};
template class T
struct is_sameT,T : true_type {};
}
namespace meta
{
inline namespace v1
{
template typename T
using _t = typename T::type;
template bool... Bools
using and_c = std::is_samestd::integer_sequencebool, Bools...,
std::integer_sequencebool, (Bools ||
true)...;
}
}
namespace stl2 { inline namespace v1 {
using std::declval;
namespace detail {
template class...
struct all_same : std::true_type {};
template class T, class...Rest
struct all_sameT, Rest... :
meta::and_c__is_same_as(T, Rest)... {};
}
template class...Ts
concept bool Same() {
return detail::all_sameTs...::value;
}
template class F, class...Args
using ResultType = decltype(declvalF()(declvalArgs()...));
template class
struct value_type {};
template class T
struct value_typeT* {
using type = T;
};
template class T
using ValueType =
typename value_typeT::type;
template class F, class...Args
concept bool Function() {
return requires (F f, Args...args) {
f((Args)args...);
requires Samedecltype(f((Args)args...)), ResultTypeF, Args... ();
};
}
template class, class... struct __function : std::false_type {};
Function{F, ...Args} struct __functionF, Args... : std::true_type {};
template class F, class I1, class I2
concept bool IndirectCallable() {
return FunctionF, ValueTypeI1, ValueTypeI2();
}
template class F, class I1, class I2
concept bool IndirectCallable2() {
return __functionF, ValueTypeI1, ValueTypeI2::value;
}
namespace ext { namespace models {
template class, class, class
constexpr bool indirect_callable() { return false; }
IndirectCallable{F, I1, I2}
constexpr bool indirect_callable() { return true; }
template class, class, class
constexpr bool indirect_callable2() { return false; }
IndirectCallable2{F, I1, I2}
constexpr bool indirect_callable2() { return true; }
}}
}}
namespace models = stl2::ext::models;
template class T = void
struct plus {
T operator()(T, T) const;
};
static_assert((models::indirect_callable::plusint, int*, int*()), Concept
check failed: models::indirect_callable::plusint, int*, int*());
static_assert((models::indirect_callable2::plusint, int*, int*()), Concept
check failed: models::indirect_callable2::plusint, int*, int*());
[Bug c++/67147] New: [concepts] ICE on checking concept with default template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147
Bug ID: 67147
Summary: [concepts] ICE on checking concept with default
template arguments
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template class F, class I1, class I2 = I1
concept bool IndirectCallableRelation() {
return true;
}
template class, class, class = void
constexpr bool indirect_relation() { return false; }
IndirectCallableRelation{F, I1}
constexpr bool indirect_relation() { return true; }
IndirectCallableRelation{F, I1, I2}
constexpr bool indirect_relation() { return true; }
leads to:
test.cpp:9:31: internal compiler error: in tsubst, at cp/pt.c:12607
IndirectCallableRelation{F, I1}
^
test.cpp:9:31: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/67148] [concepts] Failed concept check when indirecting through a constrained trait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67148
--- Comment #1 from Eric Niebler eric.niebler at gmail dot com ---
If I replace the variadic Same concept with the binary one below, the problem
goes away.
templateclass T, class U
concept bool Same() {
return __is_same_as(T,U);
}
[Bug c++/67152] New: [concepts] bogus partial specialization of ‘fooT’ after instantiation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67152
Bug ID: 67152
Summary: [concepts] bogus partial specialization of ‘fooT’
after instantiation error
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The error happens on constrained partial specializations of a template that has
already been instantiated. But the template that got instantiated would fail
the constraint anyway, so the error is complaining about nothing AFAICT.
Consider:
template class T
concept bool HasType = requires { typename T::type; };
templateclass T
struct trait {
using type = void;
};
struct has_type { using type = void; };
// Instantiation here
traithas_type::type foo() {}
// constrained version here. Type has_type would fail this
// constraint so this partial specialization would not have been
// selected.
templateclass T
requires !HasTypeT
struct traitT {
using type = void;
};
...yields the following:
test.cpp:17:8: error: partial specialization of ‘struct traitT’ after
instantiation of ‘struct traithas_type’ [-fpermissive]
struct traitT {
^
If the partial specialization is the following instead:
templateclass T
struct traitT* {
using type = void;
};
then there is no error. It seems to me that for partial specializations, a
constraints failure should be treated similarly to a pattern match failure WRT
such errors.
[Bug c++/67139] [concepts] ICE on checking concepts with void with variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139 Eric Niebler eric.niebler at gmail dot com changed: What|Removed |Added Summary|[concepts] ICE on checking |[concepts] ICE on checking |concepts with void |concepts with void with ||variable template --- Comment #3 from Eric Niebler eric.niebler at gmail dot com --- The problem goes away when _vT is replaced with the equivalent T::type::value in concept IsTrue_, so that seems to be the smoking gun.
[Bug c++/67138] New: [concepts] bogus not more constrained error for more constrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67138
Bug ID: 67138
Summary: [concepts] bogus not more constrained error for more
constrained partial specialization
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template class T
concept bool _Auto = true;
template _Auto T
struct test {};
template _Auto T
requires requires (T t) { t + t; }
struct testT {};
yields:
test.cpp:10:8: error: partial specialization ‘struct testT’ does not
specialize any template arguments and is not more constrained than
struct testT {};
^
test.cpp:6:8: note: primary template here
struct test {};
^
[Bug c++/67139] [concepts] ICE on checking concepts with void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139
--- Comment #2 from Eric Niebler eric.niebler at gmail dot com ---
Thanks, except that that is invalid code, and this bug is an ICE-on-valid.
Here's the equivalent valid repro case:
template class T
constexpr typename T::type::value_type _v = T::type::value;
template class T concept bool IsTrue_() { return _vT; }
template class T concept bool Unpossible() {
return IsTrue_T ();
}
template class constexpr bool unpossible() { return false; }
Unpossible{ T }
constexpr bool unpossible() { return true; }
static_assert((!unpossiblevoid()), );
[Bug c++/67139] New: [concepts] ICE on checking concepts with void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139 Bug ID: 67139 Summary: [concepts] ICE on checking concepts with void Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Created attachment 36141 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36141action=edit preprocessed source archive Compile the attached code with -std=gnu++1z. The result is: ../cmcstl2/test/concepts/object.cpp:254:50: internal compiler error: Segmentation fault CONCEPT_ASSERT(!models::move_constructiblevoid()); ^ ../cmcstl2/test/concepts/object.cpp:254:50: internal compiler error: Aborted g++: internal compiler error: Aborted (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Cursory attempts to reduce the test case caused the error to go away.
[Bug c++/67070] New: [concepts] Concept with negation and disjunction not checked correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
Bug ID: 67070
Summary: [concepts] Concept with negation and disjunction not
checked correctly
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Created attachment 36093
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36093action=edit
preprocessed source archive
The static assertion in the attached file fires when it shouldn't. If the
_ContainerLike concept is changed from this:
template class T
concept bool _ContainerLike =
RangeT()
Rangeconst T()
!SameReferenceTypeIteratorTypeT,
ReferenceTypeIteratorTypeconst T();
... to this:
template class T
constexpr bool __container_like() { return false; }
template Range T
requires Rangeconst T()
!SameReferenceTypeIteratorTypeT,
ReferenceTypeIteratorTypeconst T()
constexpr bool __container_like() { return true; }
template class T
concept bool _ContainerLike = __container_likeT();
... the static assertion goes away. These two seem the same to me.
[Bug c++/66988] New: [concepts] concept with template template parameter satisfied erroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66988
Bug ID: 66988
Summary: [concepts] concept with template template parameter
satisfied erroneously
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Pretty sure the static assert in the program below should not fire, but it
does.
#include type_traits
template template class... class T, class... U
concept bool _Valid = requires { typename TU...; };
template class T
using __t = typename T::type;
template class T
struct __has_type : std::false_type { };
template class T
requires _Valid__t, T
struct __has_typeT : std::true_type { };
static_assert(!__has_typeint(), );
[Bug c++/66985] New: [concept] template introduction with template template parameter and template parameter pack causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66985
Bug ID: 66985
Summary: [concept] template introduction with template template
parameter and template parameter pack causes ICE
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Code:
template template class... class T, class... U
concept bool _Valid = requires { typename TU...; };
template template class... class T, class... U
struct __defer { };
_Valid{T, ...U}
struct __deferT, U... {
using type = TU...;
};
Result:
$ /usr/local/gcc-concepts/bin/g++.exe -std=gnu++1z -c bug.cpp
bug.cpp:8:15: internal compiler error: in cp_parser_single_declaration, at
cp/parser.c:24808
_Valid{T, ...U}
^
bug.cpp:8:15: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/66988] [concepts] concept with template template parameter satisfied erroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66988
--- Comment #2 from Eric Niebler eric.niebler at gmail dot com ---
I thought that, too. But this program has the same problem:
#include type_traits
template template class class T, class U
concept bool _Valid = requires { typename TU; };
template class T
using __t = typename T::type;
template class T
struct __has_type : std::false_type { };
template class T
requires _Valid__t, T
struct __has_typeT : std::true_type { };
static_assert(!__has_typeint(), );
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #11 from Eric Niebler eric.niebler at gmail dot com --- Removing the disjunction in the Constructible concept causes memory usage and compile time to drop to zero. The word from Andrew is that this is simply a quadratic algorithm. It is unknown whether a non-quadratic algorithm that handles disjunctions exists. Given that, I think we simply need to avoid concepts with disjunctions in STL2. :-(
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #3 from Eric Niebler eric.niebler at gmail dot com --- I can't make sense of that error, or understand why you get that and I don't. You tried the command line I gave above, with the latest concept-gcc built from source?
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #9 from Eric Niebler eric.niebler at gmail dot com --- Jason, is there anything I can do in my code to avoid the quadratic explosion while we wait for Andrew to fix the bug?
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 Eric Niebler eric.niebler at gmail dot com changed: What|Removed |Added Attachment #36028|0 |1 is obsolete|| --- Comment #6 from Eric Niebler eric.niebler at gmail dot com --- Created attachment 36043 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36043action=edit regenerate the test case Regenerate the test case. Hopefully this is better.
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #1 from Eric Niebler eric.niebler at gmail dot com --- This is a blocker for STL2.
[Bug c++/66962] New: [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 Bug ID: 66962 Summary: [concepts] overloaded function causing memory blow-up and ICE Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Created attachment 36028 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36028action=edit preprocessed source Compile with: g++ -std=gnu++1z -c iterator.i.cpp Result: g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It seems to have something to do with the iter_swap2 definition. Commenting out those two functions makes the compile complete successfully (although IMO it takes longer than it should, so we're probably already in trouble).
[Bug c++/66841] [concepts] bogus error invalid reference to function concept when function concept is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66841 --- Comment #2 from Eric Niebler eric.niebler at gmail dot com --- This answer is deeply unsatisfying. I want valid expressions, not traits. And if std::is_constructible doesn't do *exactly* what I want (and it doesn't) I have to author my own trait, when what I want to do is author my own concept. I'm not trying to do anything exotic here. There should be a way to do it without resorting to metaprogramming trickery and SFINAE.
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #3 from Eric Niebler eric.niebler at gmail dot com ---
I was thinking that overloading the Constructible concept would be a conforming
way to express this, but it doesn't seems to work. Any clue why?
template class T, class U
concept bool Same = __is_same_as(T, U);
template class T, class U
concept bool ExplicitlyConvertible() { return
SameT, U ||
requires(T t) {
static_castU((T)(t));
};
}
template class T, class... Args
concept bool Constructible() { return
ExplicitlyConvertibleArgs..., T() ||
requires (Args... args) {
T{ (Args)(args)... };
};
}
template class T, class U
concept bool Constructible() { return
ExplicitlyConvertibleU, T() ||
requires (U u) {
T{ (U)(u) };
};
}
template class T, class U
requires ConstructibleT, U()
constexpr bool f() { return false; }
template class T, ExplicitlyConvertibleT
constexpr bool f() { return true; }
static_assert(fint,int(), );
static_assert(fint,long(), );
struct A {
A(int);
};
struct B {
explicit B(int);
};
static_assert(fA, int(), );
static_assert(!fB, int(), );
Yields:
/cygdrive/c/Users/eric/Code/cmcstl2/test/core_concepts.cpp:32:25: error:
invalid reference to function concept ‘templateclass T, class U constexpr
bool Constructible()’
requires ConstructibleT, U()
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/core_concepts.cpp:48:1: error: static
assertion failed
static_assert(!fB, int(), );
^
I can't make sense of the error. Is this just a bug?
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #6 from Eric Niebler eric.niebler at gmail dot com --- Exhaustively overloading Constructible to avoid the kind mismatch and the ambiguity runs into a different problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66841 I haven't filed an issue for the ambiguity/partial order problem. Should I, or is that by design? Either the kind mismatch problem needs to be fixed, or issue #66841. Right now I don't seem to have a way to express what I'm trying to express.
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #5 from Eric Niebler eric.niebler at gmail dot com --- I would expect a partial ordering to prefer the two-parameter overload in that case. But yeah, it's a separate issue.
[Bug c++/66841] New: [concepts] bogus error invalid reference to function concept when function concept is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66841
Bug ID: 66841
Summary: [concepts] bogus error invalid reference to function
concept when function concept is overloaded
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
This is related to the discussion in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834. Because of the kind
mismatch error described in 66834, the straightforward implementation of
Constructible doesn't work, and the concept must be overloaded. But once it's
overloaded, uses of it cause of invalid reference to function concept error.
template class T, class U
concept bool Same =
__is_same_as(T, U);
template class T, class U
concept bool ExplicitlyConvertible() { return
SameT, U ||
requires(T t) {
static_castU((T)t);
};
}
template class T
concept bool Constructible() { return
requires {
T{ };
};
}
template class T, class U
concept bool Constructible() { return
ExplicitlyConvertibleU, T() ||
requires (U u) {
T{ (U)u };
};
}
template class T, class U, class V, class...Args
concept bool Constructible() { return
requires (U u, V v, Args...args) {
T{ (U)u, (V)v, (Args)args... };
};
}
template class, class...
constexpr bool core_constructible() { return false; }
template class T, class...Args
requires ConstructibleT, Args...() // ERROR HERE
constexpr bool core_constructible() { return false; }
Yields:
../cmcstl2/scratch/constructible.cpp:40:23: error: invalid reference to
function concept ‘templateclass T, class U, class V, class ... Args constexpr
bool Constructible()’
requires ConstructibleT, Args...()
^
[Bug c++/66758] [concepts] ICE compiler deeply confused by simple-seeming concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66758 --- Comment #9 from Eric Niebler eric.niebler at gmail dot com --- Created attachment 35950 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35950action=edit Bug number 4 ICE ICE baby
[Bug c++/66758] [concepts] ICE compiler deeply confused by simple-seeming concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66758 Eric Niebler eric.niebler at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #10 from Eric Niebler eric.niebler at gmail dot com --- Lest I seem ungrateful, thank you for your work so far. I'm still ICE-ing the compiler, though. See the fourth attachment.
[Bug c++/66758] [concepts] ICE compiler deeply confused by simple-seeming concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66758 Eric Niebler eric.niebler at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #5 from Eric Niebler eric.niebler at gmail dot com --- The previous fix caused the code in the third attachment to stop working.
[Bug c++/66758] [concepts] ICE compiler deeply confused by simple-seeming concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66758 --- Comment #4 from Eric Niebler eric.niebler at gmail dot com --- Created attachment 35948 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35948action=edit Preprocessed source, bug the third The previous fix caused the code in attachment #3 to stop working.
[Bug c++/66832] New: [concepts] parameters in requires clauses conflicting with function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66832
Bug ID: 66832
Summary: [concepts] parameters in requires clauses conflicting
with function arguments
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template class T, class U, unsigned N
requires requires (T t, U u) { t.foo(); u.foo(); }
void foo_all( T (t)[N], U (u)[N] ) {
for(auto x : t)
x.foo();
for(auto x : u)
x.foo();
}
struct S {
void foo() {}
};
int main() {
S rg[4] {};
foo_all(rg, rg);
}
Yields:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:4:23: error: conflicting
declaration ‘T ( t)[N]’
void foo_all( T (t)[N], U (u)[N] ) {
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:3:25: note: previous
declaration as ‘T t’
requires requires (T t, U u) { t.foo(); u.foo(); }
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp: In function ‘void
foo_all(U ()[N])’:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:5:18: error: use of
parameter outside function body before ‘)’ token
for(auto x : t)
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp: In function ‘int
main()’:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:17:17: error: no matching
function for call to ‘foo_all(S [4], S [4])’
foo_all(rg, rg);
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:4:6: note: candidate:
templateclass T, class U, unsigned int N requires predicate(r
equires(T t, U u) {t-foo();u-foo();}) void foo_all(U ()[N])
void foo_all( T (t)[N], U (u)[N] ) {
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:4:6: note: template
argument deduction/substitution failed:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:17:17: note: candidate
expects 1 argument, 2 provided
foo_all(rg, rg);
^
[Bug c++/66834] New: [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
Bug ID: 66834
Summary: [concepts] concept parameter kind mismatch causes hard
error
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Before rev 225651 (the fix for #66758), the following worked. It no longer
does. Not sure if it's legit.
template class From, class To
concept bool ExplicitlyConvertible =
requires (From f) {
static_castTo((From)f);
};
template class T, class... Args
concept bool Constructible =
ExplicitlyConvertibleArgs..., T ||
requires (Args... args) {
T{((Args)(args))...};
};
template class T, class...Args
constexpr bool constructible() { return false; }
Constructible{T, ...Args}
constexpr bool constructible() { return false; }
int main() {}
Yields:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp: In function ‘constexpr
bool Constructible()’:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:9:5: error: pack
expansion argument for non-pack parameter ‘From’ of concept ‘template
class From, class To constexpr const bool ExplicitlyConvertibleFrom, To’
ExplicitlyConvertibleArgs..., T ||
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:1:11: note: declared here
template class From, class To
^
[Bug c++/66758] New: [concepts] ICE compiler deeply confused by simple-seeming concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66758 Bug ID: 66758 Summary: [concepts] ICE compiler deeply confused by simple-seeming concept definition Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Created attachment 35906 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35906action=edit preprocessed source Compile attachment with /usr/local/gcc-concepts/bin/g++.exe -std=c++1z -Tp -c foundational.cpp.i Result: /cygdrive/c/Users/eric/Code/cmcstl2/include/stl2/concepts/foundational.hpp:30:19: internal compiler error: Segmentation fault DestructibleT() ^ /cygdrive/c/Users/eric/Code/cmcstl2/include/stl2/concepts/foundational.hpp:30:19: internal compiler error: Aborted g++: internal compiler error: Aborted (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Hard for me to guess what the problem could be. A cursory attempt to reduce the error caused it to go away.
[Bug c++/66758] [concepts] ICE compiler deeply confused by simple-seeming concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66758
--- Comment #1 from Eric Niebler eric.niebler at gmail dot com ---
Created attachment 35907
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35907action=edit
preprocessed source, bug #2(?)
This might be the same bug, but the error is different. It yields:
/cygdrive/c/Users/eric/Code/cmcstl2/include/stl2/concepts/foundational.hpp:33:27:
internal compiler error: in tsubst_pack_expansion, at cp/pt.c:10578
T{ stl2::forwardArgs(args)... };
^
[Bug c++/66712] New: [concepts] variadic concepts cause havoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66712
Bug ID: 66712
Summary: [concepts] variadic concepts cause havoc
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template class T, class...Args
concept bool _Constructible_ =
requires (Args...args)
{
T{ ((Args)(args))... };
};
template class T, class...Args
constexpr bool _constructible_() { return false; }
_Constructible_{T, ...Args...}
constexpr bool _constructible_() { return true; }
struct S
{
S(int, char const *);
};
int main()
{
static_assert(_constructible_S, int, char const *(), );
}
Result:
temp.cpp: In function ‘int main()’:
temp.cpp:22:55: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:224
static_assert(_constructible_S, int, char const *(), );
^
temp.cpp:22:55: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The trouble with variadic concepts is a blocker for STL2.
[Bug c++/64970] New: Hard error instead of SFINAE for expression in nested template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64970
Bug ID: 64970
Summary: Hard error instead of SFINAE for expression in nested
template alias
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following code gives a hard error. I believe it should not.
templatetypename T
T declval();
templatetypename T
struct void_ { using type = void; };
templatetypename T
using void_t = typename void_T::type;
templateclass A, class B
struct Outer
{
templateclass C, class D
using Inner = decltype(true ? declvalC() : declvalD());
};
templateclass A, class B, typename Enable = void
struct S
{};
templateclass A, class B
struct SA, B, void_ttypename OuterA, B::template InnerA, B
{};
struct A{};
struct B{};
int main()
{
SA, B s;
}
The error:
test.cpp: In substitution of ‘templateclass A, class B templateclass C,
class D using Inner = decltype ((true ? declvalC() : declvalD())) [with C
= A; D = B; A = A; B = B]’:
test.cpp:32:13: required from here
test.cpp:15:33: error: no match for ternary ‘operator?:’ (operand types are
‘bool’, ‘A’, and ‘B’)
using Inner = decltype(true ? declvalC() : declvalD());
^
[Bug c++/64892] New: C++1y: generic lambdas, decltype(auto), and rvalue references, oh my!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64892
Bug ID: 64892
Summary: C++1y: generic lambdas, decltype(auto), and rvalue
references, oh my!
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
In the following code, gcc seems to be getting the value category wrong for the
return type of the generic lambda:
#include utility
int main()
{
using std::pair;
using std::declval;
using X = decltype(declvalpairint,int().first);
auto f = [](auto p) - decltype(auto) //((decltype(p))p).first)
{
return ((decltype(p))p).first;
};
using Y = decltype(f(declvalpairint,int()));
}
In this code, Y becomes an alias for int. I believe it should be int. X is
an alias for int, and I think it's doing the same thing. Also, if I replace
the decltype(auto) with decltype(((decltype(p))p).first) -- which is
*exactly* the return expression -- Y becomes an alias for int. Seems fishy to
me.
[Bug c++/64892] C++1y: generic lambdas, decltype(auto), and rvalue references, oh my!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64892 --- Comment #1 from Eric Niebler eric.niebler at gmail dot com --- I think this is user error. I was confused between the difference between decltype(x.y) and decltype((x.y)). It seems the decltype(auto) is semantically the same as decltype((x.y)) in this case. From that perspective, gcc is begin consistent. As for why decltype((declvalpairint,int().first)) is int instead of int, I'm guessing it's because of some subtlety of rvalue references that I don't yet grasp. I'll leave this open on the off-chance that this really is a bug, and on the off-change that someone will explain to me why it is the way it is. Sorry in advance if this is just noise.
[Bug c++/63730] New: C++11 ICE REGRESSION mangling template alias into function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63730
Bug ID: 63730
Summary: C++11 ICE REGRESSION mangling template alias into
function template
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Compile this:
template class T
using identity_t = T;
template template class class It
void test() {
}
int main() {
testidentity_t();
}
For me, with gcc 4.9.2, command-line g++ -std=gnu++11 -c test.cpp, I get:
test.cpp: In instantiation of ‘void test() [with It = identity_t]’:
test.cpp:12:22: required from here
test.cpp:6:6: internal compiler error: in write_name, at cp/mangle.c:800
void test()
^
test.cpp:6:6: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
It worked on gcc 4.9.0, but started failing in 4.9.1.
[Bug c++/63438] New: conditional operator deducing lvalues incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63438 Bug ID: 63438 Summary: conditional operator deducing lvalues incorrectly Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target: i686-pc-cygwin Problem is with the following code: int i = 0; const int j = 0; static_assert(std::is_samedecltype(true? i : j), int const ::value, ); I expect the static_assert to pass. It doesn't. It does with clang. Compiled with -std=gnu++11. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.9.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.9.0/libexec/gcc/i686-pc-cygwin/4.9.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../gcc-4.9.0/configure --prefix=/usr/local/gcc-4.9.0 --disable-bootstrap --enable-languages=c,c++ Thread model: single gcc version 4.9.0 (GCC)
[Bug c++/62219] New: [c++11] Spurious error for lambda in a friend function of a class template with a default template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62219
Bug ID: 62219
Summary: [c++11] Spurious error for lambda in a friend function
of a class template with a default template parameters
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
This code:
template class = void
struct S
{
friend void foo( S )
{
[](){};
}
};
Gives me:
test.cpp: In function ‘void foo(S template-parameter-1-1 )’:
test.cpp:6:8: error: default argument for template parameter for class
enclosing ‘foo(S template-parameter-1-1 )::lambda’
[](){};
^
I'm not sure what the error is trying to tell me. FWIW, the code compiles
cleanly with clang.
[Bug c++/61738] New: ICE using template template parameters and template aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61738
Bug ID: 61738
Summary: ICE using template template parameters and template
aliases
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Created attachment 33083
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33083action=edit
preprocessed source
The attached preprocessed code, compiled with -std=gnu++11, causes the
following ICE:
In file included from ../range-v3/include/range/v3/utility/concepts.hpp:22:0,
from ../range-v3/test/utility/concepts.cpp:12:
../range-v3/include/range/v3/utility/meta.hpp: In substitution of
‘templatetemplateclass ... class C, class ... As using meta_apply =
ranges::v3::meta_evalCAs ... [with C = ranges::v3::range_concept; As =
{std::vectorint, std::allocatorint }]’:
../range-v3/include/range/v3/range_concepts.hpp:255:61: required by
substitution of ‘templateclass T using range_concept_t =
ranges::v3::meta_applyranges::v3::range_concept, T [with T =
std::vectorint]’
../range-v3/test/utility/concepts.cpp:106:48: required from here
../range-v3/include/range/v3/utility/meta.hpp:40:47: internal compiler error:
Segmentation fault
using meta_apply = meta_evalCAs...;
^
0x94ac7f crash_signal
/home/eric/gcc-4.9.0/gcc/toplev.c:337
0x943000 layout_decl(tree_node*, unsigned int)
/home/eric/gcc-4.9.0/gcc/stor-layout.c:676
0x56d116 tsubst_decl
/home/eric/gcc-4.9.0/gcc/cp/pt.c:11159
0x5665e7 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:11501
0x56ea9b instantiate_template_1
/home/eric/gcc-4.9.0/gcc/cp/pt.c:15510
0x56ea9b instantiate_template(tree_node*, tree_node*, int)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:15560
0x5666f7 instantiate_alias_template
/home/eric/gcc-4.9.0/gcc/cp/pt.c:15590
0x5666f7 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:11528
0x56d012 tsubst_decl
/home/eric/gcc-4.9.0/gcc/cp/pt.c:11052
0x5665e7 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:11501
0x56ea9b instantiate_template_1
/home/eric/gcc-4.9.0/gcc/cp/pt.c:15510
0x56ea9b instantiate_template(tree_node*, tree_node*, int)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:15560
0x5666f7 instantiate_alias_template
/home/eric/gcc-4.9.0/gcc/cp/pt.c:15590
0x5666f7 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:11528
0x56a316 lookup_template_class_1
/home/eric/gcc-4.9.0/gcc/cp/pt.c:7636
0x56a316 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/eric/gcc-4.9.0/gcc/cp/pt.c:7862
0x5f7952 finish_template_type(tree_node*, tree_node*, int)
/home/eric/gcc-4.9.0/gcc/cp/semantics.c:2965
0x5b819a cp_parser_template_id
/home/eric/gcc-4.9.0/gcc/cp/parser.c:13467
0x5b8332 cp_parser_class_name
/home/eric/gcc-4.9.0/gcc/cp/parser.c:19185
0x5ad913 cp_parser_qualifying_entity
/home/eric/gcc-4.9.0/gcc/cp/parser.c:5540
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/60803] Trivial example of overloading in the presence of inheritance fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60803 --- Comment #3 from Eric Niebler eric.niebler at gmail dot com --- B
[Bug c++/60798] New: Access checking of template alias not done at the point of use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60798
Bug ID: 60798
Summary: Access checking of template alias not done at the
point of use
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following compiles with clang, but not with gcc-4.8.2
templatetypename Derived
using base_t = typename Derived::base_t;
templatetypename Derived
struct base
{
private:
friend Derived;
using base_t = base;
base() {}
};
templatetypename T
struct derived : basederivedT
{
using base_tderived::base_t;
};
int main()
{
derivedint d;
}
/
Result:
test.cpp: In substitution of ‘templateclass Derived using base_t = typename
Derived::base_t [with Derived = derivedint]’:
test.cpp:16:26: required from ‘struct derivedint’
test.cpp:21:16: required from here
test.cpp:9:22: error: ‘using base_t = struct basederivedint ’ is private
using base_t = base;
^
test.cpp:2:40: error: within this context
using base_t = typename Derived::base_t;
[Bug c++/60799] New: access checking within injected friend functions does not happen in the context of the enclosing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
Bug ID: 60799
Summary: access checking within injected friend functions does
not happen in the context of the enclosing class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following compiles with clang, but not with gcc-4.8.2
/
templatetypename T
struct foo;
templatetypename T
struct bar
{
private:
templatetypename U
friend struct foo;
int x_;
public:
bar() : x_(0) {}
};
templatetypename T
struct foo
{
private:
int x_;
public:
foo() : x_(0) {}
friend bool operator==(fooT f, barT b)
{
return f.x_ == b.x_;
}
};
int main()
{
fooint f;
barint b;
bool i = (f == b);
}
Result:
test.cpp: In instantiation of ‘bool operator==(fooint, barint)’:
test.cpp:32:18: required from here
test.cpp:10:7: error: ‘int barint::x_’ is private
int x_;
^
test.cpp:24:19: error: within this context
return f.x_ == b.x_;
^
[Bug c++/60803] New: Trivial example of overloading in the presence of inheritance fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60803
Bug ID: 60803
Summary: Trivial example of overloading in the presence of
inheritance fails
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following very simple code fails to compile:
///
templatetypename Ts
struct refines
: Ts
{};
struct A
{};
struct B
: refinesA
{};
struct C
: refinesB
{};
void fun(void *)
{}
templatetypename T
int fun(refinesT *)
{
return 0;
}
int main()
{
C *p = 0;
int i = fun(p);
}
[Bug c++/59361] cannot expand parenthesized pack expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 --- Comment #1 from Eric Niebler eric.niebler at gmail dot com --- Anybody?
[Bug c++/59360] New: Complicated bind expression causing infinite recursive template instantiations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59360
Bug ID: 59360
Summary: Complicated bind expression causing infinite recursive
template instantiations
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
This code compiles with clang 3.3 but doesn't compile with gcc 4.8.2 with
-std=gnu++11:
#include vector
#include functional
#include utility
#include iterator
#include algorithm
constexpr struct adjacent_finder
{
templatetypename Rng
typename Rng::const_iterator
operator()(Rng const rng) const
{
return std::adjacent_find(rng.begin(), rng.end());
}
} adjacent_find {};
constexpr struct ranger
{
templatetypename It
std::pairIt, It
operator()(It begin, It end) const
{
return std::make_pair(begin, end);
}
} range {};
constexpr struct prever
{
templatetypename It
It operator()(It begin) const
{
return std::prev(begin);
}
} prev {};
constexpr struct ender
{
templatetypename Rng
typename Rng::const_iterator
operator()(Rng const rng) const
{
return rng.end();
}
} end {};
int main()
{
using std::placeholders::_1;
auto fun = std::bind(
range,
std::bind(adjacent_find, _1),
std::bind(prev, std::bind(end, _1))
);
std::vectorint vi;
fun(vi);
}
From the error backtrace:
In file included from test2.cpp:2:0:
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1138:35: error: template
instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase
the maximum) substituting ‘templateclass _Tp typename
std::add_rvalue_reference template-parameter-1-1 ::type std::declval()
[with _Tp = std::vectorint]’
- decltype(__arg(declval_Args()...))
^
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1391:40: recursively
required by substitution of ‘templateclass _CVArg, class ... _Args decltype
(__arg((declval_Args)()...)) std::_Mu_Arg, true, false::operator()(_CVArg,
std::tuple_Args2 ...) const volatile [with _CVArg = _CVArg; _Args = {_Args
...}; _Arg = std::_Bindender(std::_Placeholder1)] [with _CVArg = const
volatile std::_Bindender(std::_Placeholder1); _Args = {std::vectorint,
std::allocatorint }]’
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1391:40: required by
substitution of ‘templateclass _CVArg, class ... _Args, unsigned int
..._Indexes decltype (__arg((declval_Args)()...)) std::_Mu_Arg, true,
false::__call(_CVArg, std::tuple_Args2 ..., const
std::_Index_tuple_Indexes ...) const volatile [with _CVArg = _CVArg; _Args =
{_Args ...}; unsigned int ..._Indexes = {_Indexes ...}; _Arg =
std::_Bindprever(std::_Bindender(std::_Placeholder1))] [with _CVArg =
std::_Bindprever(std::_Bindender(std::_Placeholder1)); _Args =
{std::vectorint, std::allocatorint }; unsigned int ..._Indexes = {0u}]’
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1143:50: template
instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase
the maximum) substituting ‘templateclass _Tp typename
std::add_rvalue_reference template-parameter-1-1 ::type std::declval()
[with _Tp = std::vectorint]’
[rest snipped...]
[Bug c++/59361] New: cannot expand parenthesized pack expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361
Bug ID: 59361
Summary: cannot expand parenthesized pack expression
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following compiles with clang but doesn't with g++ 4.8.2 with -std=gnu++11:
templatebool ...Bs
struct and_
{
constexpr static bool value{true};
};
templatetypename T
struct true_
{
constexpr operator bool() const { return true; }
};
templatetypename ...Ts
constexpr bool foo(Ts...)
{
return and_(true_Ts())...::value;
}
int main()
{
}
The error I get is:
test.cpp: In function ‘constexpr bool foo(Ts ...)’:
test.cpp:16:34: error: expected parameter pack before ‘...’
return and_(true_Ts())...::value;
^
test.cpp:16:37: error: template argument 1 is invalid
return and_(true_Ts())...::value;
^
[Bug c++/59296] New: [c++11] ref-qualified member function is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296
Bug ID: 59296
Summary: [c++11] ref-qualified member function is ambiguous
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following code fails to compile:
struct S
{
constexpr int foo() const { return 0; }
constexpr int foo() const { return 42; }
};
int main()
{
constexpr int i = S{}.foo();
}
The error I get is:
$ /usr/local/gcc-4.8.2/bin/g++ -std=gnu++11 -c test.cpp
test.cpp: In function ‘int main()’:
test.cpp:9:31: error: call of overloaded ‘foo()’ is ambiguous
constexpr int i = S{}.foo();
^
test.cpp:9:31: note: candidates are:
test.cpp:3:19: note: constexpr int S::foo() const
constexpr int foo() const { return 0; }
^
test.cpp:4:19: note: constexpr int S::foo() const
constexpr int foo() const { return 42; }
^
The code in question is not ambiguous. The object is clearly an rvalue, so the
-qualified member should be preferred.
[Bug c++/59244] New: [c++11] can't specialize template on ref-qualified member function pointer type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59244
Bug ID: 59244
Summary: [c++11] can't specialize template on ref-qualified
member function pointer type
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
I believe the following should compile:
```
templatetypename T
struct U;
templatetypename S, typename T
struct US (T::*)()
{};
templatetypename S, typename T
struct US (T::*)()
{};
templatetypename S, typename T
struct US (T::*)()
{};
```
g++ 4.8.1 in C++11 mode gives this:
```
test.cpp:9:8: error: redefinition of ‘struct US (T::*)()’
struct US (T::*)()
^
test.cpp:5:8: error: previous definition of ‘struct US (T::*)()’
struct US (T::*)()
^
test.cpp:13:8: error: redefinition of ‘struct US (T::*)()’
struct US (T::*)()
^
test.cpp:5:8: error: previous definition of ‘struct US (T::*)()’
struct US (T::*)()
^
```
[Bug c++/59123] New: [c++11] can't forward-declare an object later defined constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59123
Bug ID: 59123
Summary: [c++11] can't forward-declare an object later defined
constexpr
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Clang accepts the following. I think it's legal. g++ 4.8.1 rejects it:
// Fwd-declarations
struct S;
extern const S s;
// (... later) definitions
struct S {};
constexpr S s {};
[Bug c++/57764] New: class static constexpr variables cannot be references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57764
Bug ID: 57764
Summary: class static constexpr variables cannot be references
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
constexpr int x = 42;
struct S
{
static constexpr int const y = x;
};
constexpr int const S::y;
... gives:
$ /usr/local/gcc-4.8/bin/g++ -std=gnu++11 -c main.cpp
main.cpp:12:38: error: non-constant in-class initialization invalid for static
member ‘S::y’
static constexpr int const y = x;
^
main.cpp:12:38: error: (an out of class initialization is required)
main.cpp:12:38: error: ‘S::y’ cannot be initialized by a non-constant
expression when being declared
[Bug c++/57384] New: can't expand a parameter pack into a list of function types or function pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384
Bug ID: 57384
Summary: can't expand a parameter pack into a list of function
types or function pointer types
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
I believe all of the following 4 test cases should pass:
templatetypename ...Ts
struct list
{};
templatetypename ...Ts
struct S
{
using type1 = void(int...(Ts));// fails
using type2 = listint...(Ts);// fails
using type3 = void(int(*...)(Ts)); // fails
using type4 = listint(*...)(Ts); // works with 4.7, fails with 4.8
};
Currently (i.e. with gcc-4.8), 1-4 all fail. With gcc-4.7, (4) worked. I'm
compiling with -std=gnu++11
[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384
--- Comment #3 from Eric Niebler eric.niebler at gmail dot com ---
Interesting. I filed a similar bug against clang
(http://llvm.org/bugs/show_bug.cgi?id=16118), where Richard Smith seems to feel
the test cases should be:
templatetypename ...Ts
struct list
{};
templatetypename ...Ts
struct S
{
using type1 = void(int...(Ts));// (1) fails
using type2 = listint(Ts)...;// (2) works
using type3 = void(int(*...)(Ts)); // (3) fails
using type4 = listint(*)(Ts)...; // (4) works
};
This strikes me as ludicrously inconsistent. I think we need guidance from the
committee here. I was basing my bug report(s) on the example in 8.3.5/13 (which
shows:
templatetypename... T void f(T (* ...t)(int, int));
The suggestion that the pack expansion syntax differs depending on the context
in which the expansion occurs is, um, unsatisfactory.
[Bug c++/54440] New: [c++11] g++ prematurely applying rule that a template parameter pack cannot be followed by a template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54440
Bug #: 54440
Summary: [c++11] g++ prematurely applying rule that a template
parameter pack cannot be followed by a template
parameter
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.nieb...@gmail.com
The following code:
templateint...I
struct S
{
templatetemplatedecltype(I) class...A, templateint class B
struct T;
};
yields:
main.cpp:5:12: error: parameter pack ‘A’ must be at the end of the template
parameter list
I believe this is erroneous, as does clang developer Richard Smith. After S is
instantiated, A instantiates to a non-pack.
[Bug c++/53846] New: [c++11] memory exhaustion on simple recursive function template that uses decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846 Bug #: 53846 Summary: [c++11] memory exhaustion on simple recursive function template that uses decltype Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: eric.nieb...@gmail.com Created attachment 27738 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27738 g++ -std=gnu++11 -c test_eric2.cpp The attached code, compiled with -std=gnu++11, causes the compiler to exhaust the heap. With fewer arguments to the back() function it succeeds, but quickly runs into compile time troubles.
