[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?
