[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Last reconfirmed||2024-11-06 Ever confirmed|0 |1
[Bug c++/101463] [12/13 Regression] Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463 Patrick Palka changed: What|Removed |Added Summary|[12/13/14 Regression] Using |[12/13 Regression] Using a |a constexpr variable|constexpr variable template |template specialization as |specialization as default |default argument for|argument for non-type |non-type template parameter |template parameter of |of reference type leads gcc |reference type leads gcc to |to reject function call |reject function call --- Comment #5 from Patrick Palka --- Fixed for GCC 14.3 and 15 so far.
[Bug c++/117392] template argument deduction problem with CNTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117392 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-11-01 Keywords||rejects-valid Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115314 CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Confirmed, seems we're incorrectly treating the dependent specialization constant_wrapper<(L::value - R::value)> as if it were written constant_wrapper<(L::value - R::value), decltype(L::value - R::value)::type> i.e. the defaulted template argument lacks the implicit CTAD cast to fixed_value. So a workaround would be to add a redundant cast in the default template argument: template struct constant_wrapper;
[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Interesting, I guess 'auto x = *iter;' should never be done in generic code then?
[Bug libstdc++/104465] std::vector should satisfy std::ranges::viewable_range (P2415 for -c++2b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104465 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #7 from Patrick Palka --- P2415 has since been implemented for GCC 12+ by r12-7330-g5e1b17f038671d, so I think we can close this.
[Bug libstdc++/112641] : `drop_view::begin const` has O(n) complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641 --- Comment #3 from Patrick Palka --- > which will have 𝒪(n) complexity in the case of random-access-sized but > non-common range. As mentioned in the commit message I think the ranges::next implementation is O(n) only if the range is sized with a non-sized sentinel.
[Bug libstdc++/112641] : `drop_view::begin const` has O(n) complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug libstdc++/112349] ranges::min/max make unnecessary copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Summary|ranges::max makes |ranges::min/max make |unnecessary copies |unnecessary copies Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/117317] [12/13/14/15 Regression] An internal compiler error on call to virtual constexpr function via comparison operator in CRTP with multiple inheritance with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317 Patrick Palka changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Seems to have started with r12-4202-g09d886e671f223.
[Bug c++/117224] warning states "this" is explicit by-copy capture but it's an explicit by-reference capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117224 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- It seems GCC's warning was consistent with the C++ standard until wg21.link/p0018r3 which introduced '*this' captures and in turn changed the standard's wording to be in terms of the current object instead of the 'this' pointer. While the warning could use updating, it doesn't seem outright wrong in its current form since a by-reference capture of the current object is equivalent to a by-copy capture of the 'this' pointer (and indeed that's how it's implemented).
[Bug c++/117231] [15 regression] Incorrect code generation for std::generator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231 Patrick Palka changed: What|Removed |Added Keywords||wrong-code CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107637 --- Comment #1 from Patrick Palka --- Seems to have started with r15-3840-g650e9156656187.
[Bug c++/117054] [14/15 Regression] checking ICE on generic lambda inside a template containing constexpr-if containing instantiation of template with a NTTP defaulted to a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117054 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed, thanks for the bug report.
[Bug c++/117174] [12/13/14/15 Regression] Compiler seems to incorrectly cache SFINAE condition evaluation results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117174
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||12.4.0, 13.3.0, 14.2.0,
||15.0
Known to work||8.5.0
Last reconfirmed||2024-10-16
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Summary|Compiler seems to |[12/13/14/15 Regression]
|incorrectly cache SFINAE|Compiler seems to
|condition evaluation|incorrectly cache SFINAE
|results |condition evaluation
||results
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Target Milestone|--- |12.5
--- Comment #2 from Patrick Palka ---
Started with r9-6794-gb491c59fb554a7. Reduced:
template using void_t = void;
namespace N {
template bool f(T *);
template
void_t unrelated();
}
template
struct hasCustomFunc
{ static const bool value = false; };
template
struct hasCustomFunc>
{ static const bool value = true; };
static_assert(!hasCustomFunc::value, "");
[Bug c++/116876] GCC accepts invalid call to overloaded function template when neither is at least as specialized as the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116876 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- That [temp.deduct.partial] wording was changed with wg21.link/cwg1705. It seems GCC is behaving correctly wrt to the old wording and just hasn't implemented the new wording?
[Bug c++/116710] Deduction succeeds despite mismatch of reference kind (lvalue versus rvalue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116710 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |15.0 --- Comment #2 from Patrick Palka --- Fixed for GCC 15.
[Bug c++/105766] requires std::is_constructible<> reports 'constraint depends on itself' error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105766 Bug 105766 depends on bug 94894, which changed state. Bug 94894 Summary: avoidable instantiation of conversion function template during overload resolution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894 What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201 Bug 106201 depends on bug 94894, which changed state. Bug 94894 Summary: avoidable instantiation of conversion function template during overload resolution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894 What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug c++/94894] avoidable instantiation of conversion function template during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
Patrick Palka changed:
What|Removed |Added
Target Milestone|13.0|---
Status|RESOLVED|NEW
Resolution|FIXED |---
CC||jason at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
Good point, this PR is only partially fixed then (since GCC 13).
Avoiding the unnecessary instantiation in the original example and in your
example seems tricky in general unfortunately. GCC already shortcuts
consideration of template candidates when it sees a perfect non-template
candidate, but in these examples we want to shortcut consideration of other
non-template candidates when we see a perfect non-template candidate. IIUC
such shortcutting would be unsound because if there were multiple perfect
non-template candidates then we would overlook that and fail to diagnose
ambiguity.
(Note that the compiler needs to instantiate restrictive<0> when considering
the 'unrelated' candidate because restrictive<0> might be derived from
'unrelated' (e.g. through a partial specialization), which would make the
candidate viable after all.)
So one workaround that might work for your use case is to turn the problematic
'unrelated' overload into a template, e.g.
template void fun(unrelated) {}
[Bug c++/103884] ICE when calling static and non-static member function templates with the same parameter types and requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103884 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Patrick Palka --- Fixed since r14-6064, thus essentially a dup of PR100825 *** This bug has been marked as a duplicate of bug 100825 ***
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 --- Comment #16 from Patrick Palka --- *** Bug 103884 has been marked as a duplicate of this bug. ***
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 Patrick Palka changed: What|Removed |Added CC||blubban at gmail dot com --- Comment #15 from Patrick Palka --- *** Bug 107151 has been marked as a duplicate of this bug. ***
[Bug c++/107151] Specializing a concepted template can emit bogus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107151 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- (In reply to Jonathan Wakely from comment #2) > I think this is PR 100825 Yeah, GCC 14 successfully compiles the testcase ever since the constraint mangling patch r14-6064 *** This bug has been marked as a duplicate of bug 100825 ***
[Bug c++/70790] Can't mangle noexcept expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70790 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Assignee|nathan at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|ASSIGNED|RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #6 from Patrick Palka --- Yep, fixed for GCC 14.
[Bug c++/117054] [14/15 Regression] checking ICE on generic lambda inside a template containing constexpr-if containing instantiation of template with a NTTP defaulted to a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117054 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Keywords||ice-checking Summary|ICE on generic lambda |[14/15 Regression] checking |inside a template |ICE on generic lambda |containing constexpr-if |inside a template |containing instantiation of |containing constexpr-if |template with a NTTP|containing instantiation of |defaulted to a lambda |template with a NTTP ||defaulted to a lambda Target Milestone|--- |14.3 Status|NEW |ASSIGNED --- Comment #2 from Patrick Palka --- Started with r14-9943. It's a checking-only ICE though.
[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876 Patrick Palka changed: What|Removed |Added Last reconfirmed|2021-10-21 00:00:00 |2024-10-9 --- Comment #17 from Patrick Palka --- Reconfirmed on trunk. Are there any plans to get the WIP patch for this PR merged?
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
--- Comment #10 from Patrick Palka ---
(In reply to Patrick Palka from comment #9)
> *** Bug 116897 has been marked as a duplicate of this bug. ***
struct A {
int i = 42;
int foo() {
return [this](this auto &&self) { auto p = &i; return *p; }();
}
};
] clang++ -std=gnu++23 zc9.cc -o zc9
] g++ -std=gnu++23 zc9.cc -o zc9
zc9.cc: In lambda function:
zc9.cc:4:49: error: invalid use of non-static data member ‘A::i’
4 | return [this](this auto &&self) { auto p = &i; return *p; }();
| ^
zc9.cc:2:9: note: declared here
2 | int i = 42;
| ^
zc9.cc: In member function ‘int A::foo()’:
zc9.cc:4:64: error: void value not ignored as it ought to be
4 | return [this](this auto &&self) { auto p = &i; return *p; }();
|^~
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 Patrick Palka changed: What|Removed |Added CC||djnz00 at gmail dot com --- Comment #9 from Patrick Palka --- *** Bug 116897 has been marked as a duplicate of this bug. ***
[Bug c++/116897] lambda with deduced this parameter does not capture this properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116897 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 113563 ***
[Bug other/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 Patrick Palka changed: What|Removed |Added Target Milestone|--- |15.0 CC||ppalka at gcc dot gnu.org
[Bug c++/116418] [12/13 Regression] statement expressions as initializer for decltype auto breaks in templates with optimization turned on and debug info turned on due to gstatement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418 Patrick Palka changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13 Regression] |statement expressions as|statement expressions as |initializer for decltype|initializer for decltype |auto breaks in templates|auto breaks in templates |with optimization turned on |with optimization turned on |and debug info turned on|and debug info turned on |due to gstatement-frontiers |due to gstatement-frontiers --- Comment #11 from Patrick Palka --- Fixed for GCC 14.3 so far.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 116492, which changed state. Bug 116492 Summary: inherited constructors with concept in subclass overrides constructor in subclass https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 116492, which changed state. Bug 116492 Summary: inherited constructors with concept in subclass overrides constructor in subclass https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/116492] inherited constructors with concept in subclass overrides constructor in subclass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.3 Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #8 from Patrick Palka --- Narrowly fixed for GCC 14.3, fully fixed GCC 15, thanks for the bug report.
[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- I believe GCC, deliberately as an extension, treats NSDMIs as within the "immediate context" of a defaulted default constructor synthesis. So if NSDMI instantiation fails the defaulted constructor gets defined as deleted instead of issuing a hard error. Strictly speaking the code is ill-formed though IIUC. There's probably an existing PR about this.
[Bug c++/107390] template-nested lambda type uniqueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107390 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Fixed for GCC 15.
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 107390, which changed state. Bug 107390 Summary: template-nested lambda type uniqueness https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107390 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 116714, which changed state. Bug 116714 Summary: [14/15 Regression] Inconsistent lambda type inference in function template instance https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|14.3|15.0 --- Comment #9 from Patrick Palka --- Fixed for GCC 15, unfortunately the fix can't be backported to the 14 branch due to a depending on r15-2331 which is too risky to backport.
[Bug c++/116682] [12/13/14/15 Regression] ICE with enum definition inside a generic lamda (inside a template function) argument converting to an int with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116682 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116756 --- Comment #12 from Patrick Palka --- (In reply to Patrick Palka from comment #11) > Seems there's another bug, unrelated to local enums. If we replace the > problematic local enum: > then we instead ICE from expand_expr_real_1. Reduced and reported as PR116756
[Bug c++/116756] New: ICE from expand_expr_real_1 with recursive lambda and constexpr if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116756
Bug ID: 116756
Summary: ICE from expand_expr_real_1 with recursive lambda and
constexpr if
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
Reduced from PR116682#c11, not a regression:
struct Store {
void openDF() {
auto lambda = [this](auto& self, auto I) {
if constexpr (sizeof(I) == 1) {
auto next = [&self] { self(self, 42); };
openSeries(next);
}
};
lambda(lambda, 'c');
}
template void openSeries(T) { }
};
int main() {
Store store;
store.openDF();
}
during RTL pass: expand
: In lambda function:
:6:19: internal compiler error: in expand_expr_real_1, at expr.cc:11405
[Bug c++/116492] inherited constructors with concept in subclass overrides constructor in subclass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=113191
--- Comment #5 from Patrick Palka ---
I tried implementing the missing inherited vs non-inherited check from CWG2789
in cand_parms_match which fixes this testcase but it causes concepts-memfun4.C
(added by r14-7157) to regress with excess errors. The new errors/behavior
seem correct to me, so I must be missing something...
Before/after diff of concepts-memfun4.C:
@@ -1,3 +1,34 @@
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:26:25: error: static assertion
failed
+ 26 | static_assert(S<>{}.f() == 5);
+ | ~~^~~~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:26:25: note: the comparison
reduces to ‘(10 == 5)’
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:27:22: error: call of overloaded
‘g()’ is ambiguous
+ 27 | static_assert(S<>{}.g() == 5);
+ | ~~~^~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:10:17: note: candidate:
‘constexpr int B::g(this S&&) requires true [with T = void]’
+ 10 | constexpr int g(this S&&) requires true { return 5; }
+ | ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:21:17: note: candidate:
‘constexpr int S< >::g() [with
= void]’
+ 21 | constexpr int g() { return 10; }
+ | ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:28:22: error: call of overloaded
‘h()’ is ambiguous
+ 28 | static_assert(S<>{}.h() == 5);
+ | ~~~^~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:11:17: note: candidate:
‘constexpr int B::h() requires true [with T = void]’
+ 11 | constexpr int h() requires true { return 5; }
+ | ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:22:17: note: candidate:
‘constexpr int S< >::h(this S<
>&&) [with = void]’
+ 22 | constexpr int h(this S&&) { return 10; }
+ | ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:41:15: error: conversion from
‘S2<>’ to ‘int’ is ambiguous
+ 41 | static_assert(S2<>{} == 5);
+ | ^~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:33:13: note: candidate:
‘constexpr C< >::operator int() const [with
= void]’
+ 33 | constexpr operator int () const { return 15; }
+ | ^~~~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:9:13: note: candidate:
‘constexpr B::operator int() const requires true [with T = void]’
+9 | constexpr operator int () const requires true { return 5; }
+ | ^~~~
gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:46:22: error: request for member
‘f’ is ambiguous
46 | static_assert(S2<>{}.f() == 5); // { dg-error "ambiguous" }
| ^
@@ -16,6 +47,19 @@ gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:8:17: note:
candidate: ‘constexp
gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:51:17: note: candidate:
‘constexpr int S3< >::f() volatile [with
= void]’
51 | constexpr int f() volatile { return 10; }
| ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:64:23: warning: ISO C++ says
that these are ambiguous, even though the worst conversion for the first is
better than the worst conversion for the second:
+ 64 | static_assert(S4<>{}.f() == 5);
+ | ^~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:60:17: note: candidate 1:
‘constexpr int S4< >::f() const & [with
= void]’
+ 60 | constexpr int f() const & { return 10; }
+ | ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:8:17: note: candidate 2:
‘constexpr int B::f() const requires true [with T = void]’
+8 | constexpr int f() const requires true { return 5; }
+ | ^
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:64:26: error: static assertion
failed
+ 64 | static_assert(S4<>{}.f() == 5);
+ | ~~~^~~~
+gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:64:26: note: the comparison
reduces to ‘(10 == 5)’
gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C:75:15: error: conversion from
‘S5<>’ to ‘int’ is ambiguous
75 | static_assert(S5<>{} == 5); // { dg-error "ambiguous" }
| ^~
[Bug c++/116682] [12/13/14/15 Regression] ICE with enum definition inside a generic lamda (inside a template function) argument converting to an int with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116682
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #11 from Patrick Palka ---
Seems there's another bug, unrelated to local enums. If we replace the
problematic local enum:
@@ -67341,7 +67341,7 @@ public:
ZuUnroll::all([this, &o, &ok](auto I) {
if (!ok) return;
using Field = ZuType;
- enum { NDP = GetNDP{} };
+ static constexpr int NDP = GetNDP{};
if constexpr (Field::Code == Float)
ok = ok && m_wrRefs.template p()->write(Field::get(o));
else if constexpr (Field::Code == Fixed)
then we instead ICE from expand_expr_real_1.
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #7 from Patrick Palka --- Started with r14-2170 which caused the underlying issue to also affect variable template-ids; as Andrew pointed out the class template-id case was always broken. The problem is premature stripping of the alias in the template-id arguments, causing is_same_v to get treated as if is_same_v were written.
[Bug c++/116418] [12/13/14/15 Regression] statement expressions as initializer for decltype auto breaks in templates with optimization turned on and debug info turned on due to gstatement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug lto/83997] ICE with alias template and attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83997 --- Comment #8 from Patrick Palka --- (In reply to Jason Merrill from comment #7) > Patrick, do you want to look at this in the context of 115897? For the record I reckoned they're orthogonal issues as this PR is about attributes attached to the aliased type directly as opposed to the alias declaration https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658281.html
[Bug c++/116666] [15 Regression] firefox does not compile since r15-2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #5 from Patrick Palka ---
: In instantiation of ‘struct glsl::VectorType<__vector(4) int, 4>’:
:577:63: required from here
:106:13: error: invalid vector type for attribute ‘vector_size’
:108:22: error: invalid vector type for attribute ‘vector_size’
:110:13: error: invalid vector type for attribute ‘vector_size’
Agreed. It looks like the code is trying to apply the vector_size attribute to
an already vector type. Before r15-2331 we would prematurely strip the
vector_size attribute on the dependent alias when used as a template argument
for a dependent specialization, even though it affects the identity of the
type, so VectorType is equivalent to VectorType.
Now we don't, which AFAICT is the more desirable/consistent behavior.
Though I wonder why Clang accepts the testcase given that it also rejects
applying vector_size to a vector type directly:
template
struct X {
typedef T A __attribute__((vector_size(16)));
typedef A B __attribute__((vector_size(16))); // error
};
template struct X;
[Bug c++/116320] [12/13 Regression] ICE: Segmentation fault (perform_or_defer_access_check) since r11-1350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116320 Patrick Palka changed: What|Removed |Added Summary|[12/13/14 Regression] ICE: |[12/13 Regression] ICE: |Segmentation fault |Segmentation fault |(perform_or_defer_access_ch |(perform_or_defer_access_ch |eck) since r11-1350 |eck) since r11-1350 --- Comment #5 from Patrick Palka --- Fixed for GCC 14.3 / 15 so far.
[Bug c++/116276] [14/15 regression] multiple inheritance CTAD regression with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116276 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Keywords||rejects-valid Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 14.3 / 15.
[Bug c++/116567] [14/15 Regression] ICE when using lamdba as default non-type template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116567 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Should be fixed for GCC 14.3 / 15, thanks for the bug report.
[Bug c++/116506] [15 Regression] Destructors of temporary awaitables are executed too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Created attachment 59052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59052&action=edit reduced reproducer for register_awaits ICE FYI, the proposed patch https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661807.html also fixes an ICE from register_awaits while building stdexec, reduced reproducer attached.
[Bug c++/107522] ICE in parameter_mapping_equivalent_p on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107522 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Patrick Palka --- I had a patch for that needs refreshing: this https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607664.html
[Bug c++/80943] [DR2327] Conversion function selected in list-initialization in C++1z mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80943 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #6 from Patrick Palka --- (In reply to Artyom Kolpakov from comment #5) > Since gcc 14.1, this code again prints 1 in all modes since c++11. Ever since r14-1810, FWIW
[Bug c++/116492] inherited constructors with concept in subclass overrides constructor in subclass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Alias||cwg2789
--- Comment #4 from Patrick Palka ---
More reduced:
template
struct A {
A() requires true = delete; // #1
};
struct B : A {
using A::A;
B(); // #2
};
B b; // GCC and Clang-17 select #1, MSVC/Clang-18 select #2
This seems to be a recent behavior change in the standard,
https://wg21.link/cwg2789, which GCC doesn't fully implement, in particular the
...
if they are member functions, both are direct members of the same class, and
...
part.
[Bug c++/116477] ICE in instantiate_decl, instead of "cannot use concept as function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116477 Patrick Palka changed: What|Removed |Added Keywords||easyhack Last reconfirmed||2024-09-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed. The "cannot use concept as function" diagnostic should probably be moved up in finish_call_expr, to happen before the type dependence early exit.
[Bug c++/115616] c++20: 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 Patrick Palka changed: What|Removed |Added Resolution|FIXED |DUPLICATE See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=112288| --- Comment #4 from Patrick Palka --- Let's mark this a dup of PR112288 since the fix got backported *** This bug has been marked as a duplicate of bug 112288 ***
[Bug c++/112288] [12/13 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861 since r6-6830-g20a0c6f9bdbd78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=115616| CC||iamsupermouse at mail dot ru --- Comment #15 from Patrick Palka --- *** Bug 115616 has been marked as a duplicate of this bug. ***
[Bug c++/116567] [14/15 Regression] ICE when using lamdba as default non-type template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116567 Patrick Palka changed: What|Removed |Added Summary|ICE when using lamdba as|[14/15 Regression] ICE when |default non-type template |using lamdba as default |parameter. |non-type template ||parameter. Target Milestone|--- |14.3
[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116439 --- Comment #5 from Patrick Palka --- (In reply to Patrick Palka from comment #4) > It's correct but certainly weird that the current rules mean the second to > last decltype(auto) is invalid, because decltype(source) is S& but the > closure member is const S&.. D'oh, ignore this, I totally misinterpreted the testcase. The weird example I had in mind was https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655632.html FWIW
[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116439 --- Comment #4 from Patrick Palka --- Ah yes, that's PR115504 I think. The original fix was incorrectly stripping references from the captured variable type which was fixed for 14.2 by r15-1631. It's correct but certainly weird that the current rules mean the second to last decltype(auto) is invalid, because decltype(source) is S& but the closure member is const S&..
[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116439 Patrick Palka changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- I believe GCC 14 is behaving correctly according to the standard now. According to https://eel.is/c++draft/expr.prim.lambda#capture-note-7, decltype(source) must be S not S&, despite the by-ref capture. And a decltype(auto) deduced return type is equivalent decltype(return-expr), so it must deduce to S here as well. GCC's previous behavior was inconsistent and incorrect in the decltype(auto) case. Doing an init-capture [&source = source] yields S& because in that case there is no "original entity" (the init-capture is its own independent entity), and the note doesn't apply, I think. See also https://stackoverflow.com/questions/33854388/decltypeauto-deduced-return-type-from-lambda-capture
[Bug c++/113454] [14 regression] "assignment of read-only member" error with 483.xalancbmk from SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454 --- Comment #4 from Patrick Palka --- (In reply to edison from comment #3) > i can reproduct this error with cpu2006 483.xalancbmk and can not find any > workaround with gcc 14.1. For GCC 14 you need to modify the source file by removing the erroneous (and uninstantiated) function template definition. For GCC 15 we recently made it so that you can downgrade errors inside uninstantiated templates into warnings via -fpermissive or -Wno-error=template-body, see PR116064.
[Bug c++/116417] SFINAE on std::is_destructible cannot handle pseudo destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116417 Patrick Palka changed: What|Removed |Added Keywords||easyhack CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- For anyone interested in working on this this, it looks like we just need to give finish_pseudo_destructor_expr a 'complain' parameter and guard its diagnostics with it.
[Bug c++/101463] [12/13/14 Regression] Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463 Patrick Palka changed: What|Removed |Added Known to work||15.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Using |Using a constexpr variable |a constexpr variable |template specialization as |template specialization as |default argument for|default argument for |non-type template parameter |non-type template parameter |of reference type leads gcc |of reference type leads gcc |to reject function call |to reject function call Status|NEW |ASSIGNED
[Bug c++/115550] [coroutines] Reference to reference in promise constructor template argument corresponding to coroutine *this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115550 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.3 Status|NEW |RESOLVED --- Comment #6 from Patrick Palka --- Properly fixed for GCC 14.3
[Bug c++/115550] [coroutines] Reference to reference in promise constructor template argument corresponding to coroutine *this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115550 Bug 115550 depends on bug 104981, which changed state. Bug 104981 Summary: [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.3 --- Comment #12 from Patrick Palka --- Properly fixed for GCC 14.3
[Bug c++/116327] [14/15 Regression] ICE in coroutine with parameter preview on lambda with captures since r15-2210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Patrick Palka --- Fixed for GCC 14.3, thanks for the bug report.
[Bug c++/116379] [12/13/14/15 Regression] Type deduction error on decltype(auto) of parenthesized non-static data member since r12-5778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116379
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=103403
Target Milestone|--- |12.5
Known to fail||12.4.0, 13.3.0, 14.2.0,
||15.0
Summary|Type deduction error on |[12/13/14/15 Regression]
|decltype(auto) |Type deduction error on
||decltype(auto) of
||parenthesized non-static
||data member since r12-5778
Last reconfirmed||2024-08-15
Keywords||rejects-valid
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to work||11.5.0
CC||mpolacek at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
Confirmed, started with r12-5778.
template
struct X {
T val;
decltype(auto) value() { return (val); }
};
int main() {
int i = 0;
X x{ static_cast(i) };
using type = decltype(x.value());
using type = int&;
}
[Bug c++/116369] [12/13/14/15 Regression] temporary variable bounded to const reference with mutable field incorrectly marked as rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116369 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #6 from Patrick Palka --- Started with r9-869-g5603790dbf233c
[Bug c++/116327] [14/15 Regression] ICE in coroutine with parameter preview on lambda with captures since r15-2210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Ah, never mind then. Candidate patch posted for review at: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660212.html
[Bug c++/116320] [12/13/14/15 Regression] ICE: Segmentation fault (perform_or_defer_access_check) since r11-1350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116320 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression] |ICE: Segmentation fault |ICE: Segmentation fault |(perform_or_defer_access_ch |(perform_or_defer_access_ch |eck)|eck) since r11-1350 Status|NEW |ASSIGNED
[Bug c++/116327] [14/15 Regression] ICE in coroutine with parameter preview on lambda with captures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327 Patrick Palka changed: What|Removed |Added Last reconfirmed||2024-08-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Patrick Palka --- Confirmed, the ICE seems to only happen with -O0. Compiling with optimizations is OK
[Bug c++/116327] [14/15 Regression] ICE in coroutine with parameter preview on lambda with captures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.3 Summary|ICE in coroutine with |[14/15 Regression] ICE in |parameter preview on lambda |coroutine with parameter |with captures. |preview on lambda with ||captures. Known to work||14.1.0 Known to fail||14.2.0, 15.0
[Bug c++/116317] New: [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116317 Bug ID: 116317 Summary: [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ppalka at gcc dot gnu.org Target Milestone: --- Created attachment 58889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58889&action=edit smallish testcase Seen while building https://github.com/tcbrindle/flux as a module: $ g++ -std=c++20 -fmodules-ts flux.ii flux.ii:1:8: internal compiler error: in type_node, at cp/module.cc:9088 1 | export module flux; |^~ gcc trunk, 14, 13 ICE (with --enable-checking=release), gcc 12 doesn't. Bisection points to r13-1210 but that likely just triggered a latent modules streaming issue. The testcase could use more reduction.
[Bug c++/115783] GCC accepts invalid program involving calling explicit object member function from static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115783 Patrick Palka changed: What|Removed |Added CC||jose at serrall dot es --- Comment #7 from Patrick Palka --- *** Bug 115090 has been marked as a duplicate of this bug. ***
[Bug c++/115090] ICE in gimplify_expr, at gimplify.cc:18907 (deduced this)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115090 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Fixed for GCC 14.2/15 by the PR115783 fix *** This bug has been marked as a duplicate of bug 115783 ***
[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063 Patrick Palka changed: What|Removed |Added Target Milestone|14.0|13.4 --- Comment #9 from Patrick Palka --- Fixed for 13.4 now as well. > Thanks for fixing it. Should it be back-ported to earlier GCC versions? From > my point of view, as far back as GCC 11 would be nice. We usually only backport regression fixes (or occasionally if the fix is clearly confined to experimental language support, currently C++20 or later, which isn't the case for this fix).
[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 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed.
[Bug c++/115783] GCC accepts invalid program involving calling explicit object member function from static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115783 Patrick Palka changed: What|Removed |Added CC||waffl3x at protonmail dot com --- Comment #6 from Patrick Palka --- *** Bug 113348 has been marked as a duplicate of this bug. ***
[Bug c++/113348] ice when calling xobj member function without an object in an xobj member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113348 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- Fixed for GCC 14.2/15 by the PR115783 fix *** This bug has been marked as a duplicate of bug 115783 ***
[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 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113063 --- Comment #4 from Patrick Palka --- I think we can still narrowly fix this on the 13 branch.
[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 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Patrick Palka --- Seems we first started rejecting this after the change r14-3302, which exposed a consteval bug in the frontend, and this bug was later fixed by the consteval refactoring r14-4140. r14-3302 was later backported for GCC 13.3 as r13-7739, but r14-4140 wasn't (and doesn't seem suitable for backporting).
[Bug c++/116276] [14/15 regression] multiple inheritance CTAD regression with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116276 --- Comment #2 from Patrick Palka --- In C++20 mode it works because of the default ctor guide [over.match.class.deduct]/1.2: "If C is not defined or does not declare any constructors, an additional function template derived as above from a hypothetical constructor C()." I guess a ctor using-decl isn't considered a ctor decl, so we go ahead and include a default ctor guide, which ultimately is viable. In C++23 mode we see two viable guide candidates, the default ctor guide for Derived and the default ctor guide for Base1 (we don't see the Base2 using-decl), and overload resolution fails with ambiguity due to the unimplemented tiebreaker.
[Bug c++/116276] [14/15 regression] multiple inheritance CTAD regression with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116276 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Seems we need to implement the inherited vs non-inherited deduction guide candidate tiebreaker from P2582R1. And for some reason CLASSTYPE_CONSTRUCTORS only contains the first using decl, not both..
[Bug c++/107222] const qualifier appears in mangled NTTP value when the original object is so qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107222
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=112632
--- Comment #2 from Patrick Palka ---
Interestingly after the seemingly unrelated r14-8291 GCC 14/trunk now mangles
'print' in the #c0 testcase as
_Z5printITnDaXtl1qIXtl1Ydi1atlK1ALi1vv (can't be demangled by
c++filt)
GCC 13 mangles it as
_Z5printIXtl1qIXtl1Ydi1atlK1ALi1vv (aka void print{}>()
)
Clang mangles it as
_Z5printIXtl1qIXtl1Ydi1atl1ALi1vv (aka void print{}>())
[Bug c++/116064] [15 Regression] SPEC 2017 523.xalancbmk_r failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116064 --- Comment #8 from Patrick Palka --- One can now use -fpermissive or -Wno-error=template-body to compile TUs containing errors inside uninstantiated templates.
[Bug c++/116223] [14/15 Regression] GCC rejects program involving integral conversion in non-type template parameter with auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116223 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-08-05 CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | Status|UNCONFIRMED |NEW --- Comment #1 from Patrick Palka --- Started with r14-8291-gf1e5bf0d83ee4d.
[Bug libstdc++/111535] _RangeAdaptorClosure's (range | adaptor) operator is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111535 --- Comment #2 from Patrick Palka --- I'm not 100% sure this is needed or desirable. Doesn't > A range adaptor closure object is a unary function object that accepts a > range argument. imply that a closure object's call operator must already be constrained to take a range, making a range constraint on the pipe operator redundant? That's currently true for all standard range adaptors at least. Your example doesn't seem like a proper range adaptor closure object if it can be invoked on a non-range. And it doesn't seem desirable because why _not_ 'accept X | closure' iff 'closure(X)' is valid?
[Bug libstdc++/116217] RangeAdaptorClosure pipe operator is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116217 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 111535 ***
[Bug libstdc++/111535] _RangeAdaptorClosure's (range | adaptor) operator is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111535 Patrick Palka changed: What|Removed |Added CC||eddiejnolan at gmail dot com --- Comment #1 from Patrick Palka --- *** Bug 116217 has been marked as a duplicate of this bug. ***
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 88313, which changed state. Bug 88313 Summary: generic lambda in default template argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88313 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/88313] generic lambda in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88313 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Should be fixed for GCC 14.3.
[Bug c++/115897] [14/15 Regression] vector_size attribute on alias template has no effect when used in a dependent variable template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115897 Patrick Palka changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Patrick Palka --- The alias template with dependent attribute case is partially fixed for 14.2 and should be fully fixed for 14.3. The non-template alias with dependent attribute case should be fixed on trunk.
[Bug libstdc++/116038] ambiguous overload in bind_front caused by deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116038 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Patrick Palka --- Fixed for GCC 14.3, thanks for the bug report.
[Bug c++/115296] CTAD fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115296 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed for GCC 14.3, thanks for the bug report.
[Bug c++/116184] section attributes in COMDAT groups use wrong group name for multiple instances in same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116184
--- Comment #1 from Patrick Palka ---
The underlying issue can be demonstrated with non-template inlines as well:
inline const char* foo [[gnu::section("strings"), gnu::used]] = "foo";
inline const char* bar [[gnu::section("strings"), gnu::used]] = "bar";
gives
.sectionstrings,"awG",@progbits,foo,comdat
...
.sectionstrings,"awG",@progbits,foo,comdat
I'm afraid I don't know how to fix this, hopefully someone else can look into
it though.
[Bug c++/116015] ICE in replace_placeholders_r for simple default member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116015 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100252 --- Comment #4 from Patrick Palka --- This does look very similar to PR100252#c5
[Bug c++/115906] [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115906 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |15.0
[Bug c++/110855] std::source_location doesn't work with C++20 coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110855 Patrick Palka changed: What|Removed |Added Target Milestone|--- |15.0
[Bug c++/88313] generic lambda in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88313 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |14.3
