[Bug c++/103811] New: [c++20] ICE when a lambda is used as a template argument of another lambda's function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103811 Bug ID: 103811 Summary: [c++20] ICE when a lambda is used as a template argument of another lambda's function parameter Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- Following code causes an ICE (segfault): template struct A {}; int main() {[](A<[]{}>){};} Tested on https://godbolt.org/ , GCC trunk 12.0.0 20211222. The same thing happens if I move the nested lambda to A's default argument: template struct A {}; int main() {[](A<>){};} MSVC also ICEs on the second snippet, but not on the first.
[Bug libstdc++/103951] New: [C++2b] string_view range constructor, "exception specification ... depends on itself"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103951 Bug ID: 103951 Summary: [C++2b] string_view range constructor, "exception specification ... depends on itself" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- Following code compiles with -std=c++20 and earlier, but fails with -std=c++2b, in both GCC and Clang with libstdc++, with similar errors. I've tested both on GCC 11.2 and on trunk 12.0.0 20220109 at gcc.godbolt.org. #include struct Iter { Iter() {} Iter(std::string_view) {} // Adding `explicit` fixes the error Iter begin() const { return *this; } }; It's supposed to be used as `for (auto x : Iter(...))`, exactly like `fs::directory_iterator`, but I've removed `end()` and overloaded operators for brevity. The error message boils down to `return *this` considering the `string_view` constructor, which checks `Iter` against `contiguous_range`, which circularly checks `begin()`. I'm not sure if the code is legal or not, but the error is very unintuitive, so I decided to report it. I would expect this to be a soft SFINAE failure.
[Bug c++/107113] New: In function parameter list, `...` expanding a pack is accepted after `()` of a parameter declarator, but not before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107113 Bug ID: 107113 Summary: In function parameter list, `...` expanding a pack is accepted after `()` of a parameter declarator, but not before Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- GCC rejects this code: template struct A { void Foo(P...()); }; A a; But accepts this: template struct A { void Foo(P()...); }; A a; Only the first snippet should compile, since `...` must be located immediately before a parameter name (or a place where it would otherwise be located), as commonly seen in cases like `X &&... x`. Clang only accepts the first snippet.
[Bug c++/107111] GCC accepts invalid program involving function declaration with pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111 Egor changed: What|Removed |Added CC||iamsupermouse at mail dot ru --- Comment #3 from Egor --- The correct behavior should be to accept `V...()` and to reject `V()...`.
[Bug c++/107113] In function parameter list, `...` expanding a pack is accepted after `()` of a parameter declarator, but not before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107113 Egor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Egor --- Yep. *** This bug has been marked as a duplicate of bug 107111 ***
[Bug c++/107111] GCC accepts invalid program involving function declaration with pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111 --- Comment #4 from Egor --- *** Bug 107113 has been marked as a duplicate of this bug. ***
[Bug c++/101442] New: Destructor not called for a temporary object, if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 Bug ID: 101442 Summary: Destructor not called for a temporary object, if it Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: ---
[Bug c++/101442] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 --- Comment #1 from Egor --- Example is provided below. It prints `A()` and nothing else. I expected it to also pring `~A()`. ``` #include struct A { A() {std::cout << "A()\n";} A(const A &) = delete; A &operator=(const A &) = delete; ~A() {std::cout << "~A()\n";} }; struct B { const A &a; std::string s; }; B foo() { B ret{ A{}, "" }; return ret; } int main() { B b = foo(); } ```
[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 Egor changed: What|Removed |Added CC||iamsupermouse at mail dot ru --- Comment #4 from Egor --- Still happens on 12.1 and trunk.
[Bug c++/105967] New: Forming a pointer to ref-qualified member function using a function typedef ignores the qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105967 Bug ID: 105967 Summary: Forming a pointer to ref-qualified member function using a function typedef ignores the qualifier Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- Consider following code: #include struct A {}; using F = void() &; static_assert(std::is_same_v); GCC fails the static_assert, while Clang and MSVC accept it. Apparently `F A::*` becomes `void(A::*)()`, without `&`. Same happens for `&&`.
[Bug libstdc++/106676] New: [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676 Bug ID: 106676 Summary: [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- Since C++20, `std::iterator_traits` can auto-detect `::iterator_category`, if the iterator doesn't set it. Forward iterators require `::reference` (aka the return type of `operator*`) to be a reference (any reference), but libstdc++ only accepts lvalue references here. Example: #include #include template struct A { using value_type = std::remove_cvref_t; using difference_type = int; T operator*() const; A &operator++(); A operator++(int); bool operator==(const A &) const; }; // Ok. static_assert(std::is_same_v>::iterator_category, std::forward_iterator_tag>); // Should pass but fails, the category is `std::input_iterator_tag`. static_assert(std::is_same_v>::iterator_category, std::forward_iterator_tag>); I blame this on cppreference, which used to incorrectly say that only lvalue references are allowed there. It was fixed since then. See https://eel.is/c++draft/iterators#forward.iterators-1.3. Also see https://cplusplus.github.io/LWG/issue1211 (from 2009), which was resolved by https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html (in 2010). This was discussed on SO: https://stackoverflow.com/q/73353152 libc++ and MSVC's standard library share the exact same bug. This was tested on GCC 12.1 and on trunk (13.0.0).
[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676 --- Comment #1 from Egor --- I was told this is a wording defect. The `cpp17-forward-iterator` exposition-only concept in https://eel.is/c++draft/iterator.traits only permits lvalue references.
[Bug c++/115616] New: Friend-injecting a template function causes an ICE if you inject after trying to instantiate that function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115616 Bug ID: 115616 Summary: Friend-injecting a template function causes an ICE if you inject after trying to instantiate that function Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- The following causes an internal compiler error in GCC 14 and trunk: https://gcc.godbolt.org/z/z9PWhWvzh Same bug in Clang: https://github.com/llvm/llvm-project/issues/96485 MSVC compiles this successfully and calls `bar<10,20>()`. template void bar() {} template struct Reader { template friend void foo(Reader); }; template struct Writer { template friend void foo(Reader) {bar();} }; int main() { foo<10>(Reader{}); Writer{}; } GCC says: (this is trunk, v14 just says "segmentation fault") : In instantiation of 'void foo(Reader) [with int X = 10; T = int; int Y = ]': :19:12: required from here 19 | foo<10>(Reader{}); | ~~~^~~ :14:33: internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16362 14 | friend void foo(Reader) {bar();} | ^ 0x26cfe8c internal_error(char const*, ...) ???:0 0x97a4bb tree_vec_elt_check_failed(int, int, char const*, int, char const*) ???:0 0xcbc689 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ???:0 0xcabce3 instantiate_decl(tree_node*, bool, bool) ???:0 0xcd625b instantiate_pending_templates(int) ???:0 0xb6e830 c_parse_final_cleanups() ???:0 0xdcad68 c_common_parse_file() ???:0
[Bug c++/108335] New: New-expression doesn't perform mandatory copy elision when copy constructor is disabled with `requires`, in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108335 Bug ID: 108335 Summary: New-expression doesn't perform mandatory copy elision when copy constructor is disabled with `requires`, in a template Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- This doesn't compile, but it should: template struct A { A(int) {} A(const A &) requires false {}; // The condititon can depend on `T`, it doesn't matter. }; template void foo() { new A(A(1)); } int main() { foo(); } GCC says it doesn't have a suitable constructor to perform the copy. This starts working if I make `foo()` a non-template, or =delete `A(const A &)`, or create the object without `new`.
[Bug c++/111771] New: Incorrect "is used uninitialized" warning, as if zero-initialization didn't propagate through user-provided default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111771 Bug ID: 111771 Summary: Incorrect "is used uninitialized" warning, as if zero-initialization didn't propagate through user-provided default constructors Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- Here's the code. GCC with `-Wall -O3` warns that `x` is used uninitialized, even though it's zeroed. struct A { A() {} int x; }; struct B : A {}; int main() { B b = B(); return b.x; } Since `B` doesn't have a user-provided default constructor, value-initializing it like this performs zero-initialization, which propagates recursively (http://eel.is/c++draft/dcl.dcl#dcl.init.general-6.2) over all members, zeroing everything. Yet GCC incorrectly warns about `x` being uninitialized.
[Bug c++/111771] Incorrect "is used uninitialized" warning, as if zero-initialization didn't propagate through user-provided default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111771 --- Comment #2 from Egor --- Before calling A's constructor, it will zero `x` anyway. I was also surprised when I learned this yesterday, but it's what the standard says. 1. `()` performs value-initialization on B: http://eel.is/c++draft/dcl.dcl#dcl.init.general-16.4 2. Since B's ctor is not user-provided, that resolves to zero-initialization followed by default-initialization: http://eel.is/c++draft/dcl.dcl#dcl.init.general-9.1.2 3. Zero-initialization of B propagates to A, then propagates to `x` and zeroes it, regardless of A having a user-provided constructor or not: http://eel.is/c++draft/dcl.dcl#dcl.init.general-6.2 4. Lastly default-initialization of B calls B's constructor and in turn calls A's constructor.
[Bug libstdc++/112832] New: [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112832 Bug ID: 112832 Summary: [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- GCC doesn't seem to implement `{:?}` debug format for strings yet. Yet for some reason `std::formatter` has a `set_debug_format()` function, which causes a hard error when used (isn't SFINAE-friendly). `set_debug_format()` should be SFINAE-friendly, to allow the user to call it conditionally when available. Here's a code sample that fails to compile because of it: https://gcc.godbolt.org/z/PbfnsxE9n (still fails in GCC 14 trunk) #include #include #include #include #include template struct PreferDebugFormat { T ⌖ constexpr PreferDebugFormat(T &target) : target(target) {} }; template PreferDebugFormat(T &&) -> PreferDebugFormat &>; template struct std::formatter, CharT> : std::formatter, CharT> { using base = std::formatter, CharT>; constexpr decltype(auto) parse(std::basic_format_parse_context &parse_ctx) { if constexpr (requires{this->set_debug_format();}) this->set_debug_format(); return base::parse(parse_ctx); } template constexpr decltype(auto) format(const PreferDebugFormat &arg, std::basic_format_context &format_ctx) const { return base::format(arg.target, format_ctx); } }; template std::string ToDebugString(const T &value) { return std::format("{}", PreferDebugFormat(value)); } int main() { std::cout << ToDebugString("foo\nbar") << '\n'; // hard error == BUG std::cout << ToDebugString(std::string_view("foo\nbar")) << '\n'; // ok, no debug format yet std::cout << ToDebugString(42) << '\n'; // ok, no debug format }
[Bug c++/116090] New: [11 regression] Another -Wmaybe-uninitialized false positive with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116090 Bug ID: 116090 Summary: [11 regression] Another -Wmaybe-uninitialized false positive with std::optional Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- I'm not sure if it's an exact duplicate, since there are many bugs about -Wmaybe-uninitialized false positives. GCC warns about following code when compiled with `-std=c++17 -Werror=maybe-uninitialized -O2` (tested on GCC 11/12/13/14/trunk) https://gcc.godbolt.org/z/j44nbchza #include #include #include int main() { size_t n = 0; std::optional opt = 0.0f; extern std::vector vec; for (int elem : vec) { (void)elem; n += 1; bool Condition(void); if (Condition()) *opt += 1; else opt.reset(); } if (n && opt) { void UseValue(float); UseValue(*opt); } } Error message: : In function 'int main()': :27:17: error: '*(float*)((char*)&opt + offsetof(std::optional,std::optional::.std::_Optional_base::))' may be used uninitialized [-Werror=maybe-uninitialized] 27 | UseValue(*opt); | ^~ :8:26: note: '*(float*)((char*)&opt + offsetof(std::optional,std::optional::.std::_Optional_base::))' was declared here 8 | std::optional opt = 0.0f; | ^~~
[Bug c++/116289] New: [13.3 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116289 Bug ID: 116289 Summary: [13.3 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes Product: gcc Version: 13.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: --- This bug only affects 13.3. Works fine in 13.2 and in 14.x. Having this fixed in 13.x branch would be nice, since it affects `std::less{}`. The following code doesn't compile: (running `g++ -std=c++20`) https://gcc.godbolt.org/z/bodKevcvc #include int main() { struct A { int x = 0; auto operator<=>(const A &) const = default; }; decltype(A{} < A{}) y; } With following error: In member function 'constexpr auto main()::A::operator<=>(const main()::A&) const': cc1plus: error: taking address of an immediate function 'consteval std::__cmp_cat::__unspec::__unspec(std::__cmp_cat::__unspec*)'
[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116289 --- Comment #3 from Egor --- (In reply to Patrick Palka from comment #2) > r14-4140 ... doesn't seem suitable for backporting Fair enough. What's the procedure now, should I set status=resolved?