[Bug c++/115181] New: [ICE] internal compiler error in invalid_tparm_referent_p, at cp/pt.cc:7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181
Bug ID: 115181
Summary: [ICE] internal compiler error in
invalid_tparm_referent_p, at cp/pt.cc:7274
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Attempting to use an array literal as an NTTP.
```
template struct foo{};
foo<(int[]){1}> x;
```
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #15 from Luke Dalessandro --- (In reply to Jonathan Wakely from comment #5) > > IMO the ideal solution is for GCC to stop using whether a function is inline > as an optimisation hint. Then we wouldn't need some extra GCC-specific way > to override that. I'd vote to just do this and provide an attribute that's weaker than [[gnu::always_inline]] for those that need it. No need to change any underlying language stuff.
[Bug c++/114142] New: [coroutines]: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have reference_type in lookup_base, at cp/search.cc:252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114142
Bug ID: 114142
Summary: [coroutines]: internal compiler error: tree check:
expected record_type or union_type or qual_union_type,
have reference_type in lookup_base, at
cp/search.cc:252
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
```
#include
struct Bar {};
struct Task
{
struct promise_type
{
promise_type(Bar&) {}
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() {}
Task get_return_object() { return {}; }
};
};
struct Foo : Bar {
Task foo() {
co_await std::suspend_always();
co_return;
}
};
int main()
{
Foo x;
x.foo();
}
```
When I try and return a Task from a Derived member function and set the
promise's first parameter to the Base& I see this ICE.
In 13.2 this is a rejects-valid.
Current live example https://godbolt.org/z/9EceW8boz.
[Bug c++/113844] New: inline namespace lookup ambiguity for using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113844
Bug ID: 113844
Summary: inline namespace lookup ambiguity for using
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
namespace a {
inline namespace b {
inline int b{};
}
}
using namespace a::b; // gcc & msvc & edg reject, clang accepts
I think that by https://eel.is/c++draft/basic.lookup.udir#1 this using should
be okay, but gcc seems to be considering the a::b::b integer as a candidate,
which feels wrong. Is there somewhere else that makes this ambiguous?
[Bug c++/110256] New: passing concept to concept compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110256
Bug ID: 110256
Summary: passing concept to concept compiles
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I accidentally passed a concept to convertible_to and was surprised to see it
compile.
```
#include
template
concept b = requires (T t ) {
{ auto(t) } -> std::convertible_to;
};
static_assert(b);
```
https://godbolt.org/z/jh53n185s
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 --- Comment #16 from Luke Dalessandro --- (In reply to Luke Dalessandro from comment #15) > Thanks for looking at this. > [...] > > Also, from what I understand, I should report Andrew's reduced case as a bug > in clang, and msvc (and maybe nvc++ with its different front-end), which I > will do. I realized that this is almost certainly IFNDR so there isn't any need for me to create these reports.
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #15 from Luke Dalessandro ---
Thanks for looking at this. I'd like to report it back to boost as an issue,
but I want to make sure I understand what to tell them.
1. The error produce by Andrew's reduction ("error: satisfaction of atomic
constraint ... depends on itself") is different than the one produced in the
original code ("error: satisfaction value of atomic constraint ... changed)
from 'false' to 'true'"). I'm to understand that this isn't important here,
it's basically reacting to the same thing?
2. The fundamental problem with the boost code is the use of a constrained
`friend` template that depends on the template parameter D, that is not yet
complete when it is evaluated?
3. A fix for this issue in boost and the iterator_interface is to use a
constrained member function rather than attempting to use a constrained friend
function?
Also, from what I understand, I should report Andrew's reduced case as a bug in
clang, and msvc (and maybe nvc++ with its different front-end), which I will
do.
Thanks for looking into this.
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #8 from Luke Dalessandro ---
(In reply to Andrew Pinski from comment #7)
> I think the error message is correct.
>
> In the original code we have:
> ```
> ...
> template
> concept incrementable = regular<_Iter> && requires(_Iter __i) { { __i++
> } -> same_as<_Iter>; };
> ...
>
> namespace boost { namespace stl_interfaces { inline namespace v2 {
> template< typename D, typename IteratorConcept, typename
> DifferenceType>
> struct iterator_interface
> {
> friend constexpr bool operator>=(D lhs, D rhs)
> requires std::equality_comparable {}
> };
> ...
>
> template
> struct iterator : boost::stl_interfaces::iterator_interface,
> std::forward_iterator_tag, T>
> {
> bool operator==(iterator) const;
> };
>
> ```
> iterator is not complete until after the instantiation is finished but we
> have a std::equality_comparable which does the confusion
Right.
I was sort of surprised that that boost code could get away with a requires on
any of those CRTP functions where it uses the CRTP "D" type, but I tested
gcc-12 and all the clangs, and nvc++, and msvc 19, and gcc-13 was the only one
reporting problems here, so I went with consensus.
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 --- Comment #5 from Luke Dalessandro --- Ah, I didn't realize that. If you want to close one of the two issues that's fine with me. I sort of thought two different things were going on.
[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752 --- Comment #4 from Luke Dalessandro --- (In reply to Andrew Pinski from comment #2) > (In reply to Luke Dalessandro from comment #0) > > > > PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 fails the same > > assert but I don't know if it's the same cause. > > That bug was in the fortran front-end and has not relationship to the C++ > front-end issues. Thanks for checking.
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 --- Comment #3 from Luke Dalessandro --- One thing to note about this failure, the concept evaluation changes in gcc-13. The when I try with current trunk it actually ICEs in addition. I reported that ICE as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752.
[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752 --- Comment #3 from Luke Dalessandro --- Created attachment 55010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55010=edit Preprocessed source copied from the godbolt live link.
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 --- Comment #2 from Luke Dalessandro --- Created attachment 55009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55009=edit Preprocessed source copied from the godbolt live link included in the original text.
[Bug c++/109752] New: [ICE] in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752
Bug ID: 109752
Summary: [ICE] in check_complete_insertion, at hash-table.h:578
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following example is reduced from
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/example/node_iterator.cpp.
It causes the ICE on trunk (gcc-14).
#include
template
struct iterator : boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>
{
using base_type = boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>;
using base_type::operator++;
T& operator*() const;
iterator& operator++();
bool operator==(iterator) const;
};
static_assert(std::incrementable>);
Live: https://godbolt.org/z/n9hMW4a4b
PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 fails the same assert
but I don't know if it's the same cause.
PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 same example may
trigger gcc-13 bug (I'm not sure)
[Bug libstdc++/109751] New: boost interface_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
Bug ID: 109751
Summary: boost interface_interface fails concept check starting
in gcc-13
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following example is reduced from
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/example/node_iterator.cpp.
It compiles fine in gcc-12 but fails a concept check in gcc-13.
#include
template
struct iterator : boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>
{
using base_type = boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>;
using base_type::operator++;
T& operator*() const;
iterator& operator++();
bool operator==(iterator) const;
};
static_assert(std::incrementable>);
Live: https://godbolt.org/z/6qsx1narj
The error tells us that this requires clause changes from false to true.
friend constexpr bool operator<(D lhs, D rhs)
requires std::equality_comparable {
return (lhs - rhs) < typename D::difference_type(0);
}
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/include/boost/stl_interfaces/iterator_interface.hpp#L779
I don't think that requires clause makes any sense, but I also don't know why
the behavior would have changed from gcc-12 to gcc-13.
[Bug c++/109136] New: [concepts] initializer_list constructor constraint should require static_cast for explicit conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109136
Bug ID: 109136
Summary: [concepts] initializer_list constructor constraint
should require static_cast for explicit conversion
operator
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following concept should fail the static_assert, but passes (I should need
a static_cast here).
```
#include
template
concept implicit_convertible_to = requires(From x) {
std::initializer_list{ x };
};
struct foo {
explicit operator int();
};
static_assert(implicit_convertible_to);
```
Live: https://godbolt.org/z/GffP9f8o7
[Bug c++/108736] New: pconcepts] multidimensional subscript operator reports invalid error in requires test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736
Bug ID: 108736
Summary: pconcepts] multidimensional subscript operator reports
invalid error in requires test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following code produces an error when evaluating the concept.
auto foo(auto a, auto... i) -> decltype(auto) {
if constexpr (requires { a[i...]; }) {
return a[i...];
}
else {
return a;
}
}
int x = foo(1);
> : In instantiation of 'decltype(auto) foo(auto:1, auto:2 ...) [with
> auto:1 = int; auto:2 = {}]':
> :10:12: required from here
> :2:31: error: built-in subscript operator without expression list
> 2 | if constexpr (requires { a[i...]; }) {
> | ~^
> Compiler returned: 1
Workaround: specialize on sizeof...(i) to avoid this test when i... is empty.
Live example: https://godbolt.org/z/K3oezd1qz
[Bug c++/108669] missing error when std::vector of incomplete type has member referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669 --- Comment #3 from Luke Dalessandro --- (In reply to Jonathan Wakely from comment #2) > (In reply to Luke Dalessandro from comment #0) > > This should run afoul of the second half of > > https://eel.is/c++draft/vector#overview-4. "T shall be complete before any > > member of the resulting specialization of vector is referenced." > > > > I honestly don't know if that "shall" implies this is ill-formed or > > undefined behavior. > > The standard only defines the behaviour if T is complete, and so otherwise > it's undefined. > > In library wording we try to say explicitly when something makes the program > ill-formed. Thanks Johnathan. From that perspective this is simply a QoI diagnostic request to normalize behavior. If you want to drop the accepts-invalid tag I don’t mind.
[Bug c++/108669] New: [diagnostic] std::vector of incomplete type has member referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
Bug ID: 108669
Summary: [diagnostic] std::vector of incomplete type has member
referenced
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
In the following code example, I perform a value initialization of a
std::vector of incomplete type.
-
#include
struct B;
struct A {
std::vector _;
};
A a{}; // <--here
struct B {};
-
https://godbolt.org/z/ab5Erqc1n
This should run afoul of the second half of
https://eel.is/c++draft/vector#overview-4. "T shall be complete before any
member of the resulting specialization of vector is referenced."
I honestly don't know if that "shall" implies this is ill-formed or undefined
behavior. However, this test case has started to be rejected in clang-15 for
-std=C++20 code specifically, thus it would be a very helpful quality-of-life
improvement if gcc could issue a diagnostic for this problem as well.
[Bug c++/108563] New: [concepts] ICE (segfault) when requiring sizeof(variable_tempalate_v)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108563
Bug ID: 108563
Summary: [concepts] ICE (segfault) when requiring
sizeof(variable_tempalate_v)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following valid code causes an ICE (segfault)
template
struct foo {
static constexpr int value = 0;
};
template
inline constexpr int foo_v = foo::value;
static_assert(requires { sizeof(foo_v); });
Workaround is to use `foo::value` instead of the variable template.
Live example: https://godbolt.org/z/s7szdEdeP
[Bug c++/106086] New: ICE: trying to capture 'this' in instantiation of generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106086
Bug ID: 106086
Summary: ICE: trying to capture 'this' in instantiation of
generic lambda
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following code generates ICE
#include
#include
#include
template
struct foo {
constexpr auto operator()(std::same_as auto...) const -> int {
return 0;
}
};
template
struct bar : foo<_size>
{
constexpr auto operator()(std::array index) const -> int
{
return [&](std::index_sequence) {
return foo<_size>::operator()(index[i]...);
}(std::make_index_sequence<_size>());
}
};
bar<1> b;
int i = b({0}); // <-- ERROR
:18:58: internal compiler error: trying to capture 'this' in
instantiation of generic lambda
live: https://godbolt.org/z/TKGWME5aG
A couple of similar, closed bugs show up in the search so I've added them as
see-also. 105788 might be the same but it's listed as "ice-on-invalid-code" and
I'm fairly sure mine is valid (it refers to 100291).
[Bug c++/106084] New: using constructor fails to inherit consteval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106084
Bug ID: 106084
Summary: using constructor fails to inherit consteval
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following code sample fails to compile with gcc.
struct base {
consteval base() {}
};
struct child : base {
using base::base;
};
constexpr child i;
:8:20: error: 'this' is not a constant expression
live: https://godbolt.org/z/xf6EWx4e8
[Bug c++/106040] New: gcc reports error in aggregate when member has explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106040
Bug ID: 106040
Summary: gcc reports error in aggregate when member has
explicit constructor
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
gcc fails to compile the following example, as it seems to be treating .i{0} as
an implicit operation rather than an explicit construction. Both clang and MSVC
accept the example.
struct foo {
explicit foo(int) {}
};
struct bar {
foo i;
};
bar x {
.i{0} // <-- error:
};
error: :11:1: error: converting to 'foo' from initializer list would
use explicit constructor 'foo::foo(int)'
live: https://godbolt.org/z/hhvnGaK6c
[Bug c++/106026] ICE: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026 --- Comment #1 from Luke Dalessandro --- Actually, I take back the part about it being invalid code, I'm not sure it's invalid. The godbolt link compiles on clang-14 without error.
[Bug c++/106026] New: ICE: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026
Bug ID: 106026
Summary: ICE: error reporting routines re-entered.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 53163
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53163=edit
Eric's tag_invoke implementation.
Triggered with complicated tag_invoke + concepts. This code is erroneous (the
friend function with "requires requires" in cpos::extent and the free function
with "concepts::has_static_extent" should not both be possible.
This requires Eric Niebler's tag_invoke gist, which is somewhat complex, so I
left it in as an #include. I attached an actual copy as tag_invoke.hpp to this
PR as well.
https://godbolt.org/z/fzqEG6bnW
#include
<https://gist.githubusercontent.com/ericniebler/056f5459cf259da526d9ea2279c386bb/raw/6c63fa81442e811fea8bd6920a95c0b8229dca6c/tag_invoke.hpp>
#include
#include
#define FWD(x) static_cast(x)
namespace traits {
template
inline constexpr auto extents_v = not defined(extents_v);
}
namespace cpos {
struct extents
{
template
requires requires {
{ traits::extents_v> };
}
constexpr friend auto tag_invoke(extents, T&&) {
return traits::extents_v>;
}
constexpr auto operator()(auto&& x) const {
return tag_invoke(*this, FWD(x));
}
};
}
constexpr cpos::extents extents;
namespace concepts {
template
concept has_extents = requires (T t) {
{ extents(t) };
};
template
concept has_static_extents = has_extents and requires {
{ traits::extents_v> };
};
}
template
constexpr auto tag_invoke(cpos::extents, T&&) {
return traits::extents_v>;
}
template
struct static_tensor {
};
namespace traits {
template
inline constexpr auto extents_v> = _shape;
}
constexpr std::array matrix_shape = { 3, 3 };
auto x = static_tensor{};
static_assert(concepts::has_static_extents);
[Bug c++/105912] internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912
--- Comment #1 from Luke Dalessandro ---
Somewhat reduced testcase:
template struct A {};
template struct B {};
template
static consteval auto operator~(A) -> B {
return {};
}
A<'i'> i;
template
auto test() -> bool {
auto ii = ~i; // ICE HERE
return true;
}
int main()
{
bool i = test();
}
https://godbolt.org/z/rEf4neexc
[Bug c++/105912] New: internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912 Bug ID: 105912 Summary: internal compiler error: in extract_call_expr, at cp/call.cc:7114 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldalessandro at gmail dot com Target Milestone: --- Created attachment 53113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53113=edit output from -freport-bug ICE in complex constexpr/consteval context. I think this code is invalid. Debian testing gcc-12.1. - [ 83%] Building CXX object tests/CMakeFiles/expressions.dir/expressions.cpp.o /home/ldalessa/open/ttl/tests/expressions.cpp: In instantiation of ‘constexpr bool contraction(ttl::utils::type_args) [with T = int]’: /home/ldalessa/open/ttl/tests/expressions.cpp:589:24: required from ‘constexpr bool tests(ttl::utils::type_args) [with T = int]’ /home/ldalessa/open/ttl/tests/expressions.cpp:600:19: required from here /home/ldalessa/open/ttl/tests/expressions.cpp:149:13: internal compiler error: in extract_call_expr, at cp/call.cc:7114 149 | T dot = a(~i) * a(i); | ^~ 0x65a180 extract_call_expr(tree_node*) ../../src/gcc/cp/call.cc:7114 0x80b0cb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20971 0x819ea1 tsubst_copy_and_build_call_args ../../src/gcc/cp/pt.cc:19937 0x80ae60 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20687 0x80a6a7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20322 0x81b618 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:19491 0x822f79 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:16770 0x822f79 tsubst_init ../../src/gcc/cp/pt.cc:16774 0x81dc83 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18643 0x81cb62 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18462 0x81cb62 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18476 0x81c158 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18462 0x81c158 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18833 0x81ab7c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:26412 0x81ab7c instantiate_body ../../src/gcc/cp/pt.cc:26412 0x81b439 instantiate_decl(tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:26704 0x6d4962 cxx_eval_call_expression ../../src/gcc/cp/constexpr.cc:2664 0x6d6f68 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.cc:6720 0x6d9011 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.cc:6828 0x6d6ebe cxx_eval_constant_expression ../../src/gcc/cp/constexpr.cc:7044
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #14 from Luke Dalessandro --- Thanks for the information Iain. Is there something short-term where gcc could provide an "unimplemented" failure or warning diagnostic for requests for coroutine frames with extended alignment? This could save a lot of debugging angst.
[Bug c++/104177] [diagnostic] basic.align#9 should emit diagnostic for unsupported alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #4 from Luke Dalessandro --- Oh, that would be great. I tried relatively hard to find a bug like that, but I have previously shown a surprising level of incompetence with bugzilla search.
[Bug c++/104177] [diagnostic] basic.align#9 should emit diagnostic for unsupported alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #1 from Luke Dalessandro --- Also described in https://stackoverflow.com/questions/66546906/is-it-defined-behavior-to-place-exotically-aligned-objects-in-the-coroutine-stat.
[Bug c++/104177] New: [diagnostic] basic.align#9 should emit diagnostic for unsupported alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
Bug ID: 104177
Summary: [diagnostic] basic.align#9 should emit diagnostic for
unsupported alignas
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 52264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52264=edit
Downloaded CE example.
It appears that gcc doesn't currently support extended alignment for locals in
coroutine frames.
I believe this is **not** a bug, as I think that such extended alignment
support is implementation defined, however I believe that
https://timsong-cpp.github.io/cppwp/n4861/basic.align#9 says that a program
that requests unsupported extended alignment is ill-formed, and thus should get
a diagnostic.
Given the infrastructure required to demonstrate this bug, it's difficult for
me to provide a self contained example, however given the std::generator
support proposed in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2168r3.pdf, and
implemented in https://godbolt.org/z/T58h1W, the failure is:
#include
#include
#include
#include
struct alignas(32) Foo {
};
static std::generator foo() {
Foo m{};
fprintf(stdout, "%lu\n", uintptr_t() % alignof(Foo));
fflush(stdout);
assert(uintptr_t() % alignof(Foo) == 0);
co_yield 1;
}
int main() {
for (auto && x : foo()) {
return x;
}
}
CE link: https://godbolt.org/z/GTKPa81W8
Originally came to my attention in a discussion with
https://github.com/bniehoff.
[Bug c++/100557] [ICE] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 --- Comment #2 from Luke Dalessandro --- Still failing in trunk, here's a CE link to the preprocessed source https://godbolt.org/z/YPfTGnT5f.
[Bug c++/93320] internal compiler error: in is_base_type, at dwarf2out.c:12987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Comment #8 from Luke Dalessandro ---
I'm still seeing failures on this line in 12/trunk with the following invalid
code with std=c++17, **but not with -std=c++20**. Don't think architecture is
important.
```
struct A {
A(decltype(auto)... xs) {}
};
```
https://godbolt.org/z/neKc1M6sd
[Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911 Luke Dalessandro changed: What|Removed |Added CC||ldalessandro at gmail dot com --- Comment #10 from Luke Dalessandro --- I'm seeing this wtih gcc-11.2 on an x86_64-pc-linux-gnu system (RHEL 8.4) installed using spack. What is the right way for me to find out if this is an actual gcc regression or a packaging problem?
[Bug c++/102418] New: [concepts] prefer iterator to range concept failures in ranges (QoI)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102418
Bug ID: 102418
Summary: [concepts] prefer iterator to range concept failures
in ranges (QoI)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
When interacting with the ranges library I am occasionally presented with
hundreds of lines of circuitous concept failures driven by failing a range
concept. The vast majority of programmers won't find these helpful.
On the other hand, it was pointed out that when the failure is due to one of
the range's dependent iterator concepts, asserting the corresponding iterator
concept produces beautiful and too-the-point failure traces.
>From a QoI perspective, some mechanism to prioritize the iterator concept
failure when it is responsible for a range concept failure would go a long way
to making ranges more usable.
The example I was playing with is at https://godbolt.org/z/fGWcTdEjo, an is the
difference in output when -DITERATOR is defined in the following example.
```
struct Broken {
struct iterator {
int i;
auto operator*() const -> decltype(auto) {
return std::tie(i);
}
auto operator++() -> decltype(auto) {
++i;
return *this;
}
friend bool operator==(iterator const&, iterator const&) = default;
friend auto operator<=>(iterator const&, iterator const&) = default;
};
auto begin() const -> iterator { return {}; }
auto end() const -> iterator { return {}; }
};
#ifdef ITERATOR
static_assert(std::input_iterator);
#else
#include
int foo() {
Broken r;
std::ranges::for_each(r, [](auto t) {
auto [i] = t;
printf("%d\n", i);
});
}
#endif
```
[Bug c++/102286] [constexpr] construct_at incorrectly starts union array lifetime in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
--- Comment #2 from Luke Dalessandro ---
Okay, one last simplification for posterity.
constexpr void bar() {
union {
int data[1];
} u;
std::construct_at(u.data, 0);
}
https://godbolt.org/z/r4M3voh6W
[Bug c++/102286] [constexpr] construct_at incorrectly starts union array lifetime in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
--- Comment #1 from Luke Dalessandro ---
Oops, slightly reduced testcase, don't think the struct is necessary (just part
of my RL code).
union U {
int data[1];
constexpr U() {} // no active member
};
constexpr bool bar() {
U u;
std::construct_at([0], 0); // (1)
return true;
}
Per https://eel.is/c++draft/class.union#general-6, only assignment can start
the data array lifetime at (1). https://godbolt.org/z/6vfY6fT3d
[Bug c++/102286] New: [constexpr] construct_at incorrectly starts union array lifetime in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
Bug ID: 102286
Summary: [constexpr] construct_at incorrectly starts union
array lifetime in some cases
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Given the following struct and union,
struct Foo {
constexpr explicit Foo(int) {}
};
union U {
Foo data[1];
constexpr U() {} // no active member
};
In the function foo() below, assignment to u.data[0] correctly starts the
lifetime of the data array by https://eel.is/c++draft/class.union#general-6.
constexpr void foo() {
U u;
u.data[0] = 0; // okay
}
However in the function bar() below, [0] forms a reference before the
start of the lifetime of the data array and thus std::construct_at cannot be
used to start the lifetime of data.
constexpr void bar() {
U u;
std::construct_at([0], 0); // forms reference outside lifetime
}
Currently gcc and msvc accept this invalid code, while clang and icc reject.
See the thread of discussion at
https://lists.isocpp.org/std-proposals/2021/09/3171.php and a live example at
https://godbolt.org/z/Poh6bb5de.
[Bug c++/101155] New: comparing non-capturing lambdas is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101155
Bug ID: 101155
Summary: comparing non-capturing lambdas is not constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I think the following function pointer comparison should be constexpr.
```
auto a = []{};
auto b = []{};
static_assert(a != b); // error: '(::_FUN != ::_FUN)' is
not a constant expression
```
CE example: https://godbolt.org/z/avqPhrc6G
[Bug c++/82632] copy deduction candidate erroneously preferred over deduction-guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82632
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Comment #2 from Luke Dalessandro ---
Is this demonstrating the same behavior, and is clang wrong to accept?
```
template
struct Foo
{
Foo() = default;
Foo(Foo const&) = delete;
template
Foo(Foo const&) {}
};
template
Foo(Foo) -> Foo;
Foo a;
Foo b = a;
```
https://godbolt.org/z/njqPEKMM1
[Bug c++/101051] New: [ICE] in splice_late_return_type, at cp/pt.c:29738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101051
Bug ID: 101051
Summary: [ICE] in splice_late_return_type, at cp/pt.c:29738
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following invalid code triggers ICE in 10, 11, and trunk.
```
template
class Foo
{
constexpr operator T() -> T {}
};
```
[Bug c++/100557] [ICE] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 --- Comment #1 from Luke Dalessandro --- Created attachment 50796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50796=edit Preprocessed source (bzipped for size)
[Bug c++/100557] New: [ICE] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 Bug ID: 100557 Summary: [ICE] Internal compiler error: Error reporting routines re-entered. Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldalessandro at gmail dot com Target Milestone: --- Not sure if this duplicates https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90747. /home/ldalessa/open/ttl20/include/ttl/cpos.hpp:164:17: note: template argument deduction/substitution failed: /home/ldalessa/open/ttl20/include/ttl/cpos.hpp:164:17: note: constraints not satisfied ' Internal compiler error: Error reporting routines re-entered. 0x677082 satisfaction_cache::get() /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:2668 0x67add5 satisfy_atom /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:2942 0x67add5 satisfy_constraint_r /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:3047 0x67b1ab satisfy_normalized_constraints /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:3072 0x67918b satisfy_declaration_constraints /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:3280 0x67918b constraint_satisfaction_value /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:3300 0x6790f0 constraint_satisfaction_value /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:3311 0x67b250 constraints_satisfied_p(tree_node*, tree_node*) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/constraint.cc:3337 0x7ad8d2 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/pt.c:21686 0x646839 add_template_candidate_real /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/call.c:3456 0x646fef add_template_candidate /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/call.c:3541 0x646fef add_candidates /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/call.c:6031 0x647527 add_candidates /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/call.c:4597 0x647527 perform_overload_resolution /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/call.c:4605 0x64b285 build_new_function_call(tree_node*, vec**, int) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/call.c:4679 0x7c17bc finish_call_expr(tree_node*, vec**, bool, bool, int) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/semantics.c:2830 0x78ed56 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/pt.c:20518 0x7923c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/pt.c:16223 0x7923c2 tsubst(tree_node*, tree_node*, int, tree_node*) /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/pt.c:16223 0x6cb421 dump_template_bindings /tmp/ldalessa/spack-stage/spack-stage-gcc-11.1.0-iti6b3aunvr257imqro4hr6gsq2rc4h6/spack-src/gcc/cp/error.c:446
[Bug c++/100553] New: [constexpr] new/delete matching fails when ref-counted pointers are stored in arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100553
Bug ID: 100553
Summary: [constexpr] new/delete matching fails when ref-counted
pointers are stored in arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Sorry about the complexity of this test case. Consider the following code.
```
#include
struct Node {
int count = 0;
constexpr virtual void destroy() const = 0; // workaround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
};
struct node_ptr
{
Node *ptr_;
constexpr ~node_ptr()
{
dec();
}
constexpr node_ptr(node_ptr const& b)
: ptr_(b.ptr_)
{
inc();
}
constexpr node_ptr(node_ptr&& b)
: ptr_(std::exchange(b.ptr_, nullptr))
{
}
constexpr node_ptr(Node *ptr)
: ptr_(ptr)
{
inc();
}
constexpr node_ptr& operator=(Node* b)
{
if (b) {
++b->count;
}
dec();
ptr_ = b;
return *this;
}
constexpr void inc() const
{
if (ptr_) {
++ptr_->count;
}
}
constexpr void dec()
{
if (ptr_) {
if (--ptr_->count == 0) {
std::exchange(ptr_, nullptr)->destroy();
}
}
}
};
struct Unary : Node
{
node_ptr children[1] = { nullptr };
node_ptr a = nullptr;
constexpr void destroy() const override
{
delete this;
}
};
#ifdef ARRAY // fails
#define a(node) node->children[0]
#else
#define a(node) node->a
#endif
struct Tree
{
Unary c;
constexpr Tree(node_ptr const& tree) {
std::construct_at(, static_cast(*tree.ptr_));
a(()) = nullptr;
}
};
constexpr node_ptr foo() {
Unary *node = new Unary;
a(node) = new Unary;
return node;
}
constexpr Tree tree = foo(); // error: use of allocated storage after
deallocation in a constant expression
```
This is a fragment of some tree code that I'm using and includes a base Node*
type with a count for an intrusive node_ptr reference counted pointer. There is
one derived type, Unary, that stores a single node_ptr, either as an ARRAY or
as a scalar member. The tree stores a single Unary node.
There's a macro for the sake of the test case, -DARRAY uses the array member.
When I use the array member gcc-trunk fails to match the new/deletes, while its
fine with the scalar member. Clang compiles both without error.
https://godbolt.org/z/oGc1qTvvo
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
--- Comment #2 from Luke Dalessandro ---
It's also possible to workaround this with array allocation.
```
struct Foo {
constexpr virtual ~Foo() {}
};
constexpr bool foo() {
Foo *ptr = new Foo[1]{};
delete [] ptr;
return true;
}
static_assert(foo());
```
Obviously both of the workarounds require that we be able to cast from a `Foo*`
to our derived pointer, at which point we might as well skip the virtual
destructor and add an abstract `virtual void destroy() = 0` member where we can
just call `delete this` anyway.
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
--- Comment #1 from Luke Dalessandro ---
A short-term workaround for this appears to be explicit allocator usage (works
back at least to 10.2).
```
#include
struct Foo {
constexpr virtual ~Foo() {}
};
constexpr bool foo() {
std::allocator alloc = {};
Foo *ptr = alloc.allocate(1);
std::construct_at(ptr);
std::destroy_at(ptr);
alloc.deallocate(ptr, 1);
return true;
}
static_assert(foo());
```
https://godbolt.org/z/ohKE6h3Px
[Bug c++/100495] New: constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
Bug ID: 100495
Summary: constexpr virtual destructor incorrectly reports
memory leak
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
When using a constexpr virtual destructor gcc fails to match delete with
corresponding new.
```
struct Foo {
constexpr virtual ~Foo() {}
};
constexpr bool foo() {
Foo *ptr = new Foo();
delete ptr;
return true;
}
static_assert(foo()); //error: 'foo()' is not a constant expression because
allocated storage has not been deallocated
```
https://godbolt.org/z/W6haTEvzs
[Bug c++/93413] Destructor definition not found during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413 Luke Dalessandro changed: What|Removed |Added CC||ldalessandro at gmail dot com --- Comment #2 from Luke Dalessandro --- I just ran into this today. The referenced "dup" seems to have been resolved last June, but this is still failing. Also probably the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99495. Is there any chance someone could take a fresh look at this?
[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963 --- Comment #3 from Luke Dalessandro --- I understand. Thank you (I've forwarded this on to clang, which _does_ accept the ambiguous form).
[Bug c++/100055] New: ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055
Bug ID: 100055
Summary: ICE on invalid requires expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following invalid code triggers a segfault.
```
void foo(auto&& arg) requires({});
:1:30: error: statement-expressions are not allowed outside functions
nor in template-argument lists
1 | void foo(auto&& arg) requires({});
| ^
:1:33: internal compiler error: Segmentation fault
1 | void foo(auto&& arg) requires({});
| ^
0x1d01009 internal_error(char const*, ...)
???:0
0x7a1b17 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x7a7a78 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0x8e230d c_parse_file()
???:0
0xa615b2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
ASM generation compiler returned: 1
```
live example: https://godbolt.org/z/qjWWWchjo
[Bug c++/99963] New: [concepts] template vs concept auto reports ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963
Bug ID: 99963
Summary: [concepts] template vs concept auto reports
ambiguous overload
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Consider the following code (https://godbolt.org/z/h1bz1qxan).
#include
struct A{};
struct B : A {};
template
concept is_a = std::is_base_of_v;
template
concept is_b = is_a and std::same_as;
int foo(is_a auto, is_a auto);
#ifdef OK
int foo(is_b auto, is_a auto);
#else
template
int foo(is_b auto, A);
#endif
A a;
B b;
int d = foo(b, a);
:23:12: error: call of overloaded 'foo(B&, A&)' is ambiguous
23 | int d = foo(b, a);
| ~~~^~
With -DOK, which enables is_a auto syntax, this compiles. The template
fails.
[Bug c++/99885] New: CTAD fails for auto const& NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99885
Bug ID: 99885
Summary: CTAD fails for auto const& NTTP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following (much-reduced) code causes a CTAD failure in gcc but not clang
(https://godbolt.org/z/zWhWGj7PE) with both C++17 and C++20.
template
struct Foo {};
template
struct Bar {
constexpr auto foo() const -> Foo {
return {};
}
};
constexpr int a = 1;
constexpr Bar bar;
Foo foo = bar.foo(); // <-- CTAD failure
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #1 from Luke Dalessandro --- It was pointed out that it _also_ works if I change > static_assert(foo()); to > constexpr bool b = foo(); > static_assert(b); static_assert(foo());
[Bug c++/99859] New: constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 Bug ID: 99859 Summary: constexpr evaluation with member function is incorrect Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldalessandro at gmail dot com Target Milestone: --- I'm at a loss for how to describe this. I have an intrusive reference counting smart pointer that manipulates the pointed-to object's `count_` member either explicitly or via a member function. The explicit version works fine, the member function does not (both are fine in clang). See the difference with -DUSE_DEC in https://godbolt.org/z/rhb7e6rjr.
[Bug c++/99059] Static inline variable can't refer to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059 --- Comment #2 from Luke Dalessandro --- Ran into this in a static constexpr initializer, not really a workaround for it that I can find.
[Bug c++/97790] constexpr evaluation reports false positive memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
--- Comment #1 from Luke Dalessandro ---
It is possible to workaround this bug by creating a symbol for the offending
allocation in the IILE.
https://godbolt.org/z/jeoEra
```
struct vector {
int *data;
int n;
constexpr vector() : data(new int[1]{}), n(1) {}
constexpr ~vector() { delete [] data; }
};
struct Foo {
constexpr auto foo() const {
return vector();
}
};
template
constexpr static auto bar() {
[] {
auto temp = f.foo(); // <-- GIVE THIS A NAME
return temp.n;
}();
return true;
}
constexpr Foo foo;
constexpr auto dd = bar();
```
[Bug c++/97790] New: constexpr evaluation reports false positive memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
Bug ID: 97790
Summary: constexpr evaluation reports false positive memory
leak
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The constexpr evaluator seems to lose track of dynamic allocations in some
contexts, resulting in false-positive leaks and rejected valid code.
This particular example uses an immediately invoked function expression
referencing an NTTP, which seems like a corner case but is actually extremely
common in two-pass constexpr algorithms (i.e., compute constexpr size of
result, then compute result to return).
https://godbolt.org/z/Tnn6xh
```
struct vector {
int *data;
int n;
constexpr vector() : data(new int[1]{}), n(1) {}
constexpr ~vector() { delete [] data; }
};
struct Foo {
constexpr auto foo() const {
return vector();
}
};
template
constexpr static auto bar() {
[] { return f.foo().n; }();
return true;
}
constexpr Foo foo;
constexpr auto dd = bar();
```
[Bug c++/96115] Char literal, decays to a pointer when passed to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96115
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Comment #1 from Luke Dalessandro ---
This continues to be a problem in gcc trunk, and impacts real code that
attempts to use `std::span` arguments.
Templates are not necessary to reproduce this behavior.
https://godbolt.org/z/PYreGK
```
struct span
{
span( int (&)[2] ) {}
};
bool foo(span) {
return true;
}
bool baz(bool ()(span), int i, int j) {
int array[] = {i, j};
int ()[2] = array;
return op(ref);
}
auto x = baz(foo, 1, 2);
```
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
--- Comment #5 from Luke Dalessandro ---
The more I think about this the more it bothers me.
I recognize that it might be very difficult to implement in gcc's
infrastructure, but I think the design decision that "if it _can_ be constant
evaluated it _will_ be constant evaluated" is too aggressive.
Consider https://godbolt.org/z/cTYPaK.
```
[[gnu::noinline]]
constexpr int a(int x) {
return x + 1;
}
int main() {
int i = a(1);
return i;
}
```
1. The function is marked noinline.
2. The code is compile with "-O0 -g".
3. The calling context is not explicitly `constexpr`.
The fact that gcc _still_ chooses to constant evaluate `a` at best violates the
principle of least surprise, and at worst makes it impractical to use gcc to
debug more complex codebases. Honestly, the `noinline` annotation shouldn't
even be necessary, `a` should simply not be constant evaluated with `-O0`. It's
not practical to find all of the uses of `a` and modify their call sites.
>From a software engineering perspective I believe that gcc must provide some
way to disable this behavior.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #4 from Luke Dalessandro --- There are other occurrences of `a` that _are_ in `constexpr` context, it is used in both contexts within the application thus the keyword is necessary. This report came from a testcase reduction, so I'll have to look into what's going on in the real calling context (presumably it's *already* not `constexpr` there so it might not be an issue in practice in that context). I'd still suggest that a user that explicitly asks for `noinline`, even for a `constexpr` function, would expect `noinline` to take precedence over constant expression propagation, as the clang results provide. Perhaps some diagnostic warning can be manifested if constant expression evaluation is overriding the attribute? Thanks for the explanation.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #2 from Luke Dalessandro --- Okay, how would one constrain such inlining in order to retain a symbol and stack frame for debugging purposes?
[Bug c++/97681] New: noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
Bug ID: 97681
Summary: noinline attribute ignored on constexpr function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
GCC inlines function marked noinline when the function is marked as
`constexpr`, even if it is not used in `constexpr` context.
https://godbolt.org/z/b94Kje
```
[[gnu::noinline]] constexpr auto a() { return 1; }
[[gnu::noinline]] auto b() { return 2; }
int main() {
int i = a();
int j = b();
return i + j;
}
```
```
b():
mov eax, 2
ret
main:
callb()
add eax, 1
ret
```
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #7 from Luke Dalessandro --- Thank you, sorry for the confusion.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #5 from Luke Dalessandro --- Ugh... replying to myself. > You can do Foo foo = Foo(); and it compiles. >> 1. I can't do `Foo foo = Foo();` because the purpose of the union is to >> allocate uninitialized storage for the `Foo` during `constexpr` execution >> when `Foo` has no default constructor. I realize now I meant to write >> `constexpr Foo() = delete;`. This means to say "trivial default constructor," not just "default constructor". The empty default constructor was an adequate test case for this, but is misleading. The `= delete` should be more effective as an example. The context for the use is to create an array that provides uninitialized vector storage during `constexpr` evaluation in the same way a `std::byte[T*sizeof(T)]` array combined with `reinterptret_cast` might be used during normal execution.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #4 from Luke Dalessandro ---
Hi Jakob,
Thank you for looking at this. I restructured the code sample according to your
suggestions and it is available here https://godbolt.org/z/P1bMEz. I don't
understand a couple of things that you said, and ultimately I'm not sure if you
are agreeing that this could be a bug.
> You can do Foo foo = Foo(); and it compiles.
1. I can't do `Foo foo = Foo();` because the purpose of the union is to
allocate uninitialized storage for the `Foo` during `constexpr` execution when
`Foo` has no default constructor. I realize now I meant to write `constexpr
Foo() = delete;` in the original code. I _can_ use the monostate to have an
active member at initialization, but would prefer not to as it complicates the
union.
> clang++ rejects it too:
> error: constexpr union constructor that does not initialize any member is a
> C++20 extension [-Werror,-Wc++20-extensions] though only with
> -pedantic-errors.
2. I can't get clang to emit the warning you describe even with the provided
flags, perhaps I am doing it wrong or misinterpreting your comment.
> P1331R2 support is there since
> r10-5194-g7906797ebec6881d7d90165340f51efcf447d716
> (so without [1] it is accepted for -std=c++2a since that revision)
3. I think this means that, if the member is not an array, then it is accepted
with `-std=c++2a`. I do observe this, however it's not my use case. Technically
I have an array of some class template parameter `N`.
The updated test case with the deleted constructor is.
```
struct Foo {
constexpr Foo() = delete;
};
union U {
// struct {} monostate = {};
Foo foo;
constexpr U() {}
};
struct V {
U storage[1];
};
constexpr V v;
```
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #1 from Luke Dalessandro --- (In reply to Luke Dalessandro from comment #0) > GCC currently rejects the following code snippet, where it infers the > constexpr definition of V as non-constexpr. The definition of `v`, not the type `V`. I apologize.
[Bug c++/97665] New: constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
Bug ID: 97665
Summary: constexpr union array member incorrectly rejected as
non-constexpr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
GCC currently rejects the following code snippet, where it infers the constexpr
definition of V as non-constexpr. The monostate member provides a temporary
workaround.
https://godbolt.org/z/Ph1n1P
```
struct Foo {
constexpr Foo() {}
};
union U {
// struct {} monostate = {};
Foo foo;
constexpr U() {}
};
struct V {
U storage[1];
};
constexpr V v;
```
[Bug c++/97664] New: constexpr evaluation incorrectly accepts non-constant destruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97664
Bug ID: 97664
Summary: constexpr evaluation incorrectly accepts non-constant
destruction
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
This one involves some language-lawyering, which is not my forte.
While developing a constexpr, array-based vector that supports non-default
constructible types, I have run into the following inconsistency between clang
and gcc.
https://godbolt.org/z/PYdq5P
```
#include
struct Foo {
mutable int n = 0;
};
union U {
Foo foo;
constexpr U() {}
};
struct cvector {
U storage[1];
constexpr cvector() {
std::construct_at([0].foo);
}
constexpr ~cvector() {
std::destroy_at([0].foo);
}
};
constexpr cvector v;
```
After some slack discussion that I didn't entirely follow, it seems that
http://eel.is/c++draft/expr.const#7.2 combined with
http://eel.is/c++draft/expr.const#6.2 may exclude the constexpr use of
destroy_at of an instance of a class with mutable members. I am not confident
with this analysis, nor am I confident that this is desirable behavior, but am
reporting it for consideration.
[Bug c++/97427] New: constexpr destructor for const object incorrectly rejected as modifying const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97427
Bug ID: 97427
Summary: constexpr destructor for const object incorrectly
rejected as modifying const object
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The destructor below is rejected (see https://godbolt.org/z/M8YxTY). Workaround
for now is to mark n as mutable.
```
struct Foo {
int n = 1;
constexpr ~Foo() {
n = 0;
}
};
constexpr bool foo() {
const Foo b;
return true;
}
static_assert(foo());
```
The write to n is flagged as below.
```
:13:18: error: non-constant condition for static assertion
13 | static_assert(foo());
| ~~~^~
:13:18: in 'constexpr' expansion of 'foo()'
:9:15: in 'constexpr' expansion of '((Foo*)(& b))->Foo::~Foo()'
:4:11: error: modifying a const object '((Foo*)this)->Foo::n' is not
allowed in a constant expression
4 | n = 0;
```
[Bug c++/85576] A template union containing a friend function causes non-template type used as a template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576 --- Comment #1 from Luke Dalessandro --- Just ran into this today while testing 11. https://godbolt.org/z/37G7P5 Any possibility we'll see a fix soon?
[Bug c++/97328] New: [ICE] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
Bug ID: 97328
Summary: [ICE] internal compiler error: in verify_ctor_sanity,
at cp/constexpr.c:3995
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following code causes ICE, but *ONLY* when explicitly passing `-std=c++20`.
```
template
struct vector {
union storage {
T t;
constexpr storage() {}
} data[N];
};
constexpr auto foo() {
vector i;
return i;
}
auto f = foo();
```
See https://godbolt.org/z/hYYeq8.
[Bug c++/95422] New: Possible false positive for -Waddress-of-packed-member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95422
Bug ID: 95422
Summary: Possible false positive for
-Waddress-of-packed-member.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I get some confusing results from the following code.
https://godbolt.org/z/p5uZgH
> struct [[ gnu::packed ]] Foo {
> Foo() : x{} {} // <-- #1, x{}
> void* x[1];
> } foo;
>
> struct [[ gnu::packed ]] Bar {
> Bar() : x() {} // <-- #2, x() !!!-Waddress-of-packed-member!!!
> void* x[1];
> } bar;
>
> struct FooBar {
> FooBar() : x() {} // <-- #3, x(), no packed attr
> void* x[1];
> } foobar;
I'm seeing the -Waddress-of-packed-member trigger for #2 with g++ (clang++
never produces it), and I can't figure out why this particular use is special.
[Bug c++/92650] internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92650
--- Comment #1 from Luke Dalessandro ---
x86-64 gcc (trunk) - cached
#1 with x86-64 gcc (trunk)
In file included from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/action/action.hpp:19,
from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/action.hpp:17,
from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/all.hpp:17,
from :1:
/opt/compiler-explorer/libs/rangesv3/trunk/include/meta/meta.hpp: In
substitution of 'template using if_c =
meta::_t, Args
...> > > [with bool If = std::integral_constant >::value; Args = {}]':
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/common_tuple.hpp:65:13:
required from 'struct ranges::detail::args_<1, const int&>'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/concepts.hpp:1107:13:
required from 'constexpr const bool
concepts::defs::constructible_from,
ranges::detail::args_<1, const int&> >'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/common_tuple.hpp:136:9:
required by substitution of 'template
ranges::common_tuple::common_tuple(const std::tuple<_Tps ...>&,
std::enable_if_t<(constructible_from,
ranges::detail::args_ > &&
concepts::detail::CPP_true(concepts::detail::Nil{})), concepts::detail::Nil>)
[with Us = {int}]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:92:41:
required by substitution of 'template struct
concepts::detail::_builtin_common_2() : declval()))> > [with T = ranges::common_tuple; U =
std::tuple&]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:365:12:
recursively required by substitution of 'template struct
concepts::detail::_common_reference2::type>::value>::invoke > [with T
= ranges::common_tuple; U = std::tuple&]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:365:12:
required from 'struct concepts::common_reference,
std::tuple&>'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:370:11:
required by substitution of 'template using common_reference_t
= typename concepts::common_reference::type [with Ts =
{ranges::common_tuple, std::tuple&}]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/common_type.hpp:58:11:
required by substitution of 'template using common_reference_t
= concepts::common_reference_t [with Ts =
{ranges::detail::if_then::apply > > >::cursor,
true>, ranges::common_tuple >, meta::id >::type&}]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/iterator/basic_iterator.hpp:453:19:
required from 'struct
ranges::detail::iterator_associated_types_base_ > > >::cursor,
true>'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/iterator/basic_iterator.hpp:492:31:
required from 'struct
ranges::basic_iterator > > >::cursor >'
:17:16: required from here
/opt/compiler-explorer/libs/rangesv3/trunk/include/meta/meta.hpp:1222:11:
internal compiler error: canonical types differ for identical types
'std::integral_constant >' and
'std::integral_constant >'
1222 | using if_c = _t, Args...>>>;
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/92650] New: internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92650
Bug ID: 92650
Summary: internal compiler error: canonical types differ for
identical types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 47349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47349=edit
test case
Following code triggers ICE on (godbolt) trunk only. See
https://godbolt.org/z/q4CrvX.
It's hard for me to disambiguate from other reports with the same error
message, but it seems new.
#include
struct Wrapper {
int a[1];
constexpr operator int() const { return a[0]; }
};
int main() {
std::vector a;
auto all = ranges::views::all(a);
auto zip = ranges::views::zip(a);
Wrapper b;
*all.begin() = b;
*zip.begin() = b;
}
[Bug c++/90480] [8/9/10 Regression] ICE when calling operator() inside a lambda defined in a template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480 --- Comment #3 from Luke Dalessandro --- Created attachment 47336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47336=edit Testcast
[Bug c++/90480] [8/9/10 Regression] ICE when calling operator() inside a lambda defined in a template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480
--- Comment #2 from Luke Dalessandro ---
I'm hitting this with the following similar, but different snippet. Maybe it
will help with this.
#include
struct Foo {
int operator()(int i) {
return 0;
}
template
auto operator()(std::array ids) {
return std::apply([&](auto...) {
return operator()(0);
}, ids);
}
};
int main() {
Foo foo;
foo(std::array{0, 1});
}
[Bug c++/86875] internal compiler error: in tsubst_copy, at cp/pt.c:15478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86875 --- Comment #1 from Luke Dalessandro --- Created attachment 44515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44515=edit Preprocessed source
[Bug c++/86875] New: internal compiler error: in tsubst_copy, at cp/pt.c:15478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86875
Bug ID: 86875
Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:15478
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
ICE in 8.2 (Debian gcc package) when capturing `const` variable in y_combinator
recursive lambda. This code works fine in 7.x. Capturing by reference or copy
makes no difference. Removing `const` suppresses the ICE.
Attached reduced test.ii test case.
* g++ -std=c++14 -c -o test.o test.ii
* Linux ** 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64
GNU/Linux
* gcc version 8.2.0 (Debian 8.2.0-1)
* Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
-
# Terminal session with details #
-
$ uname -a
Linux ** 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64
GNU/Linux
$ gcc --version
gcc (Debian 8.2.0-1) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat test.cpp
#include
// Adapted from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0200r0.html.
template
class y_combinator_result {
Fun fun_;
public:
template
explicit y_combinator_result(T &): fun_(std::forward(fun)) {}
template
decltype(auto) operator()(Args &&...args) {
return fun_(std::ref(*this), std::forward(args)...);
}
};
template
decltype(auto) y_combinator(Fun &) {
return y_combinator_result>(std::forward(fun));
}
int main() {
const unsigned w = 1; // non-const works fine
auto foo = y_combinator([=](auto foo) -> void {
auto i = 0 + w;
foo();
});
foo();
return 0;
}
$ g++ -v -std=c++14 -save-temps -c -o test.o test.cpp
Using built-in specs.
COLLECT_GCC=g++
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-1)
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-save-temps' '-c' '-o' 'test.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -std=c++14
-fpch-preprocess -o test.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/
