[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 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&action=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{&i});
| ^
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/../inclu
[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++/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++/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++/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++/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++/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&action=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++/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 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++/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:
template
struct S
{
template class...A, template 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++/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:
template
struct list
{};
template
struct S
{
using type1 = void(int...(Ts));// fails
using type2 = list;// fails
using type3 = void(int(*...)(Ts)); // fails
using type4 = list; // 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 ---
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:
template
struct list
{};
template
struct S
{
using type1 = void(int...(Ts));// (1) fails
using type2 = list;// (2) works
using type3 = void(int(*...)(Ts)); // (3) fails
using type4 = list; // (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:
template 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++/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++/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.
[Bug c++/53036] New: [c++11] trivial class fails std::is_trivial test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
Bug #: 53036
Summary: [c++11] trivial class fails std::is_trivial test
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
In my understanding of the new C++ standard, the following code should compile.
It does not.
struct D
{
D() = default;
D(D const &) = default;
template
constexpr D(U ...u)
{}
};
static_assert(std::is_trivial::value, "here");
The problem is the variadic constexpr constructor. I'm guessing here that the
problem is that it could also be used as a default constructor, making the type
non-trivial. However, I have explicitly defaulted the default constructor, so
the variadic constructr should never be considered for 0 arguments.
I base the above supposition on the fact that if I add a dummy argument to the
variadic as below, it works:
struct D
{
D() = default;
D(D const &) = default;
template
constexpr D(int, U ...u) // dummy arg, not default c'tor, ok.
{}
};
static_assert(std::is_trivial::value, "here");
[Bug c++/53096] New: [c++11] should be possible to default a copy ctor that takes non-const arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53096
Bug #: 53096
Summary: [c++11] should be possible to default a copy ctor that
takes non-const arg
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 does not compile:
struct foo
{
foo() = default;
foo(foo &) = default; // ERROR HERE
foo(foo const &) = default;
};
The error is:
error: ‘foo::foo(foo&)’ declared to take non-const reference
cannot be defaulted in the class body
This was correct for the FDIS, but is now incorrect given the resolution for
core issue 1333:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1333
The code above should be accepted.
[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++/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:
```
template
struct U;
template
struct U
{};
template
struct U
{};
template
struct U
{};
```
g++ 4.8.1 in C++11 mode gives this:
```
test.cpp:9:8: error: redefinition of ‘struct U’
struct U
^
test.cpp:5:8: error: previous definition of ‘struct U’
struct U
^
test.cpp:13:8: error: redefinition of ‘struct U’
struct U
^
test.cpp:5:8: error: previous definition of ‘struct U’
struct U
^
```
[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++/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
#include
#include
#include
#include
constexpr struct adjacent_finder
{
template
typename Rng::const_iterator
operator()(Rng const & rng) const
{
return std::adjacent_find(rng.begin(), rng.end());
}
} adjacent_find {};
constexpr struct ranger
{
template
std::pair
operator()(It begin, It end) const
{
return std::make_pair(begin, end);
}
} range {};
constexpr struct prever
{
template
It operator()(It begin) const
{
return std::prev(begin);
}
} prev {};
constexpr struct ender
{
template
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::vector 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 ‘template typename
std::add_rvalue_reference< >::type std::declval()
[with _Tp = std::vector&]’
-> decltype(__arg(declval<_Args>()...))
^
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1391:40: recursively
required by substitution of ‘template decltype
(__arg((declval<_Args>)()...)) std::_Mu<_Arg, true, false>::operator()(_CVArg&,
std::tuple<_Args2 ...>&) const volatile [with _CVArg = _CVArg; _Args = {_Args
...}; _Arg = std::_Bind)>] [with _CVArg = const
volatile std::_Bind)>; _Args = {std::vector >&}]’
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1391:40: required by
substitution of ‘template 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::_Bind)>)>] [with _CVArg =
std::_Bind)>)>; _Args =
{std::vector >&}; 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 ‘template typename
std::add_rvalue_reference< >::type std::declval()
[with _Tp = std::vector&]’
[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:
template
struct and_
{
constexpr static bool value{true};
};
template
struct true_
{
constexpr operator bool() const { return true; }
};
template
constexpr bool foo(Ts...)
{
return and_<(true_())...>::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_())...>::value;
^
test.cpp:16:37: error: template argument 1 is invalid
return and_<(true_())...>::value;
^
[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++/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())), 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())),
int>::type)
^
[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()::]’:
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++/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
constexpr bool is_same = false;
template
constexpr bool is_same = true;
template
struct indirected : F {
indirected(F f) : F(f) {}
template
auto operator()(I i) -> decltype(declval()(*i)) {
return static_cast(*this)(*i);
}
};
int main() {
auto f = [](auto rng) {
static_assert(is_same, "");
return 42;
};
indirected i(f);
static_assert(is_same())), 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():: [with auto:1 = int*]’:
repro.cpp:17:25: required by substitution of ‘template
main()operator decltype
(((main()::)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, "");
^
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();
} 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 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 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 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 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 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 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 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++/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 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++/59361] cannot expand parenthesized pack expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 --- Comment #1 from Eric Niebler --- Anybody?
[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
template
using base_t = typename Derived::base_t;
template
struct base
{
private:
friend Derived;
using base_t = base;
base() {}
};
template
struct derived : base>
{
using base_t::base_t;
};
int main()
{
derived d;
}
/
Result:
test.cpp: In substitution of ‘template using base_t = typename
Derived::base_t [with Derived = derived]’:
test.cpp:16:26: required from ‘struct derived’
test.cpp:21:16: required from here
test.cpp:9:22: error: ‘using base_t = struct base >’ 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
/
template
struct foo;
template
struct bar
{
private:
template
friend struct foo;
int x_;
public:
bar() : x_(0) {}
};
template
struct foo
{
private:
int x_;
public:
foo() : x_(0) {}
friend bool operator==(foo f, bar b)
{
return f.x_ == b.x_;
}
};
int main()
{
foo f;
bar b;
bool i = (f == b);
}
Result:
test.cpp: In instantiation of ‘bool operator==(foo, bar)’:
test.cpp:32:18: required from here
test.cpp:10:7: error: ‘int bar::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:
///
template
struct refines
: Ts
{};
struct A
{};
struct B
: refines
{};
struct C
: refines
{};
void fun(void *)
{}
template
int fun(refines *)
{
return 0;
}
int main()
{
C *p = 0;
int i = fun(p);
}
[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 --- B
[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&action=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++/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
int main()
{
using std::pair;
using std::declval;
using X = decltype(declval>().first);
auto f = [](auto && p) -> decltype(auto) //((decltype(p)&&)p).first)
{
return ((decltype(p)&&)p).first;
};
using Y = decltype(f(declval>()));
}
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 --- 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((declval>().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++/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.
template
T && declval();
template
struct void_ { using type = void; };
template
using void_t = typename void_::type;
template
struct Outer
{
template
using Inner = decltype(true ? declval() : declval());
};
template
struct S
{};
template
struct S::template Inner>>
{};
struct A{};
struct B{};
int main()
{
S s;
}
The error:
test.cpp: In substitution of ‘template template using Inner = decltype ((true ? declval() : declval())) [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 ? declval() : declval());
^
[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
using identity_t = T;
template class It>
void test() {
}
int main() {
test();
}
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++/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=33083&action=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
‘template class C, class ... As> using meta_apply =
ranges::v3::meta_eval > [with C = ranges::v3::range_concept; As =
{std::vector >}]’:
../range-v3/include/range/v3/range_concepts.hpp:255:61: required by
substitution of ‘template using range_concept_t =
ranges::v3::meta_apply [with T =
std::vector]’
../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_eval>;
^
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++/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< >)’:
test.cpp:6:8: error: default argument for template parameter for class
enclosing ‘foo(S< >)::’
[](){};
^
I'm not sure what the error is trying to tell me. FWIW, the code compiles
cleanly with clang.
[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_same::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++/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
concept bool _Constructible_ =
requires (Args&&...args)
{
T{ ((Args&&)(args))... };
};
template
constexpr bool _constructible_() { return false; }
_Constructible_{T, ...Args...}
constexpr bool _constructible_() { return true; }
struct S
{
S(int, char const *);
};
int main()
{
static_assert(_constructible_(), "");
}
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_(), "");
^
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++/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=35906&action=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 Destructible() && ^ /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 ---
Created attachment 35907
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35907&action=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::forward(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 #4 from Eric Niebler --- Created attachment 35948 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35948&action=edit Preprocessed source, bug the third The previous fix caused the code in attachment #3 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 Eric Niebler changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #5 from Eric Niebler --- The previous fix caused the code in the third attachment 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
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:
template 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
concept bool ExplicitlyConvertible =
requires (From&& f) {
static_cast((From&&)f);
};
template
concept bool Constructible =
ExplicitlyConvertible ||
requires (Args&&... args) {
T{((Args&&)(args))...};
};
template
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
constexpr const bool ExplicitlyConvertible’
ExplicitlyConvertible ||
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:1:11: note: declared here
template< class From, class To >
^
[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 --- Created attachment 35950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35950&action=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 changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #10 from Eric Niebler --- 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++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #3 from Eric Niebler ---
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
concept bool Same = __is_same_as(T, U);
template
concept bool ExplicitlyConvertible() { return
Same ||
requires(T&& t) {
static_cast((T&&)(t));
};
}
template
concept bool Constructible() { return
ExplicitlyConvertible() ||
requires (Args&&... args) {
T{ (Args&&)(args)... };
};
}
template
concept bool Constructible() { return
ExplicitlyConvertible() ||
requires (U&& u) {
T{ (U&&)(u) };
};
}
template
requires Constructible()
constexpr bool f() { return false; }
template >
constexpr bool f() { return true; }
static_assert(f(), "");
static_assert(f(), "");
struct A {
A(int);
};
struct B {
explicit B(int);
};
static_assert(f(), "");
static_assert(!f(), "");
Yields:
/cygdrive/c/Users/eric/Code/cmcstl2/test/core_concepts.cpp:32:25: error:
invalid reference to function concept ‘template constexpr
bool Constructible()’
requires Constructible()
^
/cygdrive/c/Users/eric/Code/cmcstl2/test/core_concepts.cpp:48:1: error: static
assertion failed
static_assert(!f(), "");
^
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 #5 from Eric Niebler --- 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
concept bool Same =
__is_same_as(T, U);
template
concept bool ExplicitlyConvertible() { return
Same ||
requires(T&& t) {
static_cast((T&&)t);
};
}
template
concept bool Constructible() { return
requires {
T{ };
};
}
template
concept bool Constructible() { return
ExplicitlyConvertible() ||
requires (U&& u) {
T{ (U&&)u };
};
}
template
concept bool Constructible() { return
requires (U&& u, V&& v, Args&&...args) {
T{ (U&&)u, (V&&)v, (Args&&)args... };
};
}
template
constexpr bool core_constructible() { return false; }
template
requires Constructible() // ERROR HERE
constexpr bool core_constructible() { return false; }
Yields:
../cmcstl2/scratch/constructible.cpp:40:23: error: invalid reference to
function concept ‘template constexpr
bool Constructible()’
requires Constructible()
^
[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 --- 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++/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 --- 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++/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=36028&action=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++/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 --- This is a blocker for 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 --- 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 Eric Niebler changed: What|Removed |Added Attachment #36028|0 |1 is obsolete|| --- Comment #6 from Eric Niebler --- Created attachment 36043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36043&action=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 #9 from Eric Niebler --- 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++/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 class T, class... U>
concept bool _Valid = requires { typename T; };
template class T, class... U>
struct __defer { };
_Valid{T, ...U}
struct __defer {
using type = T;
};
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] 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
template class T, class... U>
concept bool _Valid = requires { typename T; };
template
using __t = typename T::type;
template
struct __has_type : std::false_type { };
template
requires _Valid<__t, T>
struct __has_type : std::true_type { };
static_assert(!__has_type(), "");
[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 ---
I thought that, too. But this program has the same problem:
#include
template class T, class U>
concept bool _Valid = requires { typename T; };
template
using __t = typename T::type;
template
struct __has_type : std::false_type { };
template
requires _Valid<__t, T>
struct __has_type : std::true_type { };
static_assert(!__has_type(), "");
[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 --- 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++/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=36093&action=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
concept bool _ContainerLike =
Range() &&
Range() &&
!Same>,
ReferenceType>>();
... to this:
template
constexpr bool __container_like() { return false; }
template
requires Range() &&
!Same>,
ReferenceType>>()
constexpr bool __container_like() { return true; }
template
concept bool _ContainerLike = __container_like();
... the static assertion goes away. These two seem the same to me.
[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
concept bool _Auto = true;
template <_Auto T>
struct test {};
template <_Auto T>
requires requires (T t) { t + t; }
struct test {};
yields:
test.cpp:10:8: error: partial specialization ‘struct test’ does not
specialize any template arguments and is not more constrained than
struct test {};
^
test.cpp:6:8: note: primary template here
struct test {};
^
[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=36141&action=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_constructible()); ^ ../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++/67139] [concepts] ICE on checking concepts with void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139
--- Comment #2 from Eric Niebler ---
Thanks, except that that is invalid code, and this bug is an ICE-on-valid.
Here's the equivalent valid repro case:
template
constexpr typename T::type::value_type _v = T::type::value;
template concept bool IsTrue_() { return _v; }
template concept bool Unpossible() {
return IsTrue_();
}
template constexpr bool unpossible() { return false; }
Unpossible{ T }
constexpr bool unpossible() { return true; }
static_assert((!unpossible()), "");
[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 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 --- The problem goes away when _v is replaced with the equivalent T::type::value in concept IsTrue_, so that seems to be the smoking gun.
[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
concept bool IndirectCallableRelation() {
return true;
}
template
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] 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;
template
struct integer_sequence
{
typedef _Tp value_type;
static constexpr size_t size() { return sizeof...(_Idx); }
};
template
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
constexpr T integral_constant::value;
using true_type = integral_constant;
using false_type = integral_constant;
template
struct is_same : false_type {};
template
struct is_same : true_type {};
}
namespace meta
{
inline namespace v1
{
template
using _t = typename T::type;
template
using and_c = std::is_same,
std::integer_sequence>;
}
}
namespace stl2 { inline namespace v1 {
using std::declval;
namespace detail {
template
struct all_same : std::true_type {};
template
struct all_same :
meta::and_c<__is_same_as(T, Rest)...> {};
}
template
concept bool Same() {
return detail::all_same::value;
}
template
using ResultType = decltype(declval()(declval()...));
template
struct value_type {};
template
struct value_type {
using type = T;
};
template
using ValueType =
typename value_type::type;
template
concept bool Function() {
return requires (F& f, Args&&...args) {
f((Args&&)args...);
requires Same >();
};
}
template struct __function : std::false_type {};
Function{F, ...Args} struct __function : std::true_type {};
template
concept bool IndirectCallable() {
return Function, ValueType>();
}
template
concept bool IndirectCallable2() {
return __function, ValueType>::value;
}
namespace ext { namespace models {
template
constexpr bool indirect_callable() { return false; }
IndirectCallable{F, I1, I2}
constexpr bool indirect_callable() { return true; }
template
constexpr bool indirect_callable2() { return false; }
IndirectCallable2{F, I1, I2}
constexpr bool indirect_callable2() { return true; }
}}
}}
namespace models = stl2::ext::models;
template
struct plus {
T operator()(T, T) const;
};
static_assert((models::indirect_callable<::plus, int*, int*>()), "Concept
check failed: " "models::indirect_callable<::plus, int*, int*>()");
static_assert((models::indirect_callable2<::plus, int*, int*>()), "Concept
check failed: " "models::indirect_callable2<::plus, int*, int*>()");
[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 ---
If I replace the variadic Same concept with the binary one below, the problem
goes away.
template
concept bool Same() {
return __is_same_as(T,U);
}
[Bug c++/67152] New: [concepts] bogus "partial specialization of ‘foo’ after instantiation" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67152
Bug ID: 67152
Summary: [concepts] bogus "partial specialization of ‘foo’
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
concept bool HasType = requires { typename T::type; };
template
struct trait {
using type = void;
};
struct has_type { using type = void; };
// Instantiation here
trait::type foo() {}
// constrained version here. Type "has_type" would fail this
// constraint so this partial specialization would not have been
// selected.
template
requires !HasType
struct trait {
using type = void;
};
...yields the following:
test.cpp:17:8: error: partial specialization of ‘struct trait’ after
instantiation of ‘struct trait’ [-fpermissive]
struct trait {
^
If the partial specialization is the following instead:
template
struct trait {
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 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 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] 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 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 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++/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&action=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++/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++/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++/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++/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&action=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++/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++/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++/115378] New: [ice-on-valid] code using friend injection is crashing gcc since 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115378
Bug ID: 115378
Summary: [ice-on-valid] code using friend injection is crashing
gcc since 14
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: ---
the following valid code crashes gcc-14 and gcc-trunk. clang accepts it, as
does gcc-13. see https://godbolt.org/z/s9frvq3Pv
#include
#include
#include
#include
#include
#include
#include
#if defined(__GNUC__)
#pragma GCC diagnostic ignored "-Wpragmas"
#pragma GCC diagnostic ignored "-Wunknown-warning-option"
#pragma GCC diagnostic ignored "-Wnon-template-friend"
#endif
namespace std::execution {
template
concept __has_query =
requires (const Env& __env, Args&&... __args) {
__env.query(Query(), std::forward(__args)...);
};
// specialization for key/value pairs
template
struct prop {
[[no_unique_address]] Query __query;
[[no_unique_address]] Value __value;
[[nodiscard]] constexpr const Value & query(Query) const noexcept {
return __value;
}
};
template
prop(Query, Value) -> prop>;
template
struct __ref;
template
struct __ref {
Env& __env;
constexpr __ref(reference_wrapper __r) noexcept : __env(__r) {}
template
requires __has_query
constexpr decltype(auto) query(Query __q, Args&&... args) const
noexcept(noexcept(__env.query(__q, std::forward(args)...))) {
return __env.query(__q, std::forward(args)...);
}
};
template
struct __reader {
friend auto __counted_flag(__reader);
};
template
struct __writer {
friend auto __counted_flag(__reader) {}
static constexpr size_t __n = N;
};
template
consteval auto __counter_impl() {
constexpr bool __counted_past_value = requires(__reader __r)
{
__counted_flag(__r);
};
if constexpr (__counted_past_value) {
return __counter_impl();
} else {
return __writer().__n;
}
}
template()>
constexpr auto __counter = Val;
template struct __list;
template
struct __ignore {
constexpr __ignore(auto&&) {}
auto query(auto) const = delete;
};
template
using __wrap = conditional_t, __ref, Env>;
template
using _as_base_ = conditional_t, __ignore>;
template >>
using _as_base = _as_base_;
// utility for joining multiple environments
template
struct env : _as_base, Envs>... {
template
constexpr decltype(auto) __get_1st() const noexcept {
constexpr bool __flags[] = {__has_query...};
constexpr size_t __idx = ranges::find(__flags, true) - __flags;
auto __tup = tie(static_cast&>(*this)...);
return get<__idx>(__tup);
}
template
requires (__has_query ||...)
constexpr decltype(auto) query(Query __q, Args&&... args) const
noexcept(noexcept(__get_1st().query(__q,
std::forward(args)...))) {
return __get_1st().query(__q,
std::forward(args)...);
}
};
template
env(Envs...) -> env...>;
} // std::execution
// Test code:
template
struct get_value_t {
auto operator()(const auto& env) const noexcept -> decltype(env.query(*this))
{
static_assert(noexcept(env.query(*this)));
return env.query(*this);
}
};
template
inline constexpr get_value_t get_value{};
int main() {
using namespace std::execution;
// can create an environment out of a query and a value
auto env1 = prop(get_value<0>, 42);
auto val = get_value<0>(env1);
assert(val == 42);
// can store a value by reference:
int i = 42;
auto env2 = prop(get_value<0>, std::ref(i));
int& j = get_value<0>(env2);
++j;
assert(i == 43);
// Can create an env from several envs with duplicates.
// Queries are resolved by asking the nested envs first to last.
auto env3 = env(prop(get_value<0>, 42),
prop(get_value<1>, 43),
prop(get_value<1>, 44),
prop(get_value<0>, 45),
prop(get_value<0>, 46));
assert(get_value<0>(env3) == 42);
assert(get_value<1>(env3) == 43);
// nested envs can be held by reference also:
auto env4 = env(prop(get_value<1>, 42), std::cref(env2));
assert(get_value<0>(env4) == 43);
assert(get_value<1>(env4) == 42);
}
[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 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++/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
