[Bug c++/120123] [11/12/13/14/15 Regression] Implicit this is not used in a requires clause in nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123 --- Comment #1 from Valentin Tolmer --- Note that the code compiles with gcc 11.2, but starts breaking with gcc 11.3

[Bug c++/120123] New: Implicit this is not used in a requires clause in nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123 Bug ID: 120123 Summary: Implicit this is not used in a requires clause in nested lambdas Product: gcc Version: 15.2.1 Status: UNCONFIRMED Severity: normal

[Bug c++/118763] [12/13/14/15 regression] memory leak involving early return from statement expressions since r12-6325

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118763 --- Comment #5 from Valentin Tolmer --- Note that there's the same issue with calling a class initializer with multiple arguments (but not a function or a constructor). Refactored example to remove ASAN: ``` #include struct s { char c_;

[Bug c++/118763] [12/13/14/15 regression] memory leak involving early return from statement expressions since r12-6325

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118763 --- Comment #4 from Valentin Tolmer --- I noticed that the standard (or at least cppreference) says that "The call to the allocation function (operator new) is sequenced before(since C++17) the evaluation of the constructor arguments in a new ex

[Bug c++/118763] [12/13/14/15 regression] memory leak involving early return from statement expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118763 --- Comment #1 from Valentin Tolmer --- Potentially related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113579 Though in this case, I'm pretty sure according to the docs, it's not undefined behavior.

[Bug c++/118763] New: [12/13/14/15 regression] memory leak involving early return from statement expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118763 Bug ID: 118763 Summary: [12/13/14/15 regression] memory leak involving early return from statement expressions Product: gcc Version: 15.0 Status: UNCONFIRMED 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 --- Comment #3 from Valentin Tolmer --- Digging a little bit into it, there is definitely a bug that was in 14.1 only (and got fixed in 14.2): struct S { S() = default; S(const S&) = delete; }; int main() { S source; S& source2 = sourc

[Bug c++/116439] New: [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 Bug ID: 116439 Summary: [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture Product: gcc Version: 14.1.0

[Bug c++/116418] [12/13/14/15 Regression] Nested statement expressions with decltype auto in template break

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418 --- Comment #2 from Valentin Tolmer --- Sorry, typo in the last sentence: "the templated function doesn't have to be instantiated to trigger the bug". See https://godbolt.org/z/3xosx5dn4 for a reproduction. Adding an instantiation gives an add

[Bug c++/116418] New: [11/12/13/14/15 Regression] Nested statement expressions with decltype auto in template break

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418 Bug ID: 116418 Summary: [11/12/13/14/15 Regression] Nested statement expressions with decltype auto in template break Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug c++/116062] New: Exponentially slow compilation at -O3 with __attribute__((flatten))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116062 Bug ID: 116062 Summary: Exponentially slow compilation at -O3 with __attribute__((flatten)) Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal

[Bug c++/116038] New: [14/15 Regression] ambiguous overload in bind_front caused by deducing this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116038 Bug ID: 116038 Summary: [14/15 Regression] ambiguous overload in bind_front caused by deducing this Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity:

[Bug c++/115986] [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986 --- Comment #3 from Valentin Tolmer --- Some notes: - The fact that the static_assert fails is not relevant. Changing b() to return 1 still exhibits the error. - The branch taken in `long f = true ? 0 : b(long(1));` matters; it only fails if b i

[Bug c++/115986] New: [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving user-defined uint128 literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986 Bug ID: 115986 Summary: [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving user-defined uint128 literals Product: gcc Version: 14.0

[Bug c++/115900] [14 Regression] constexpr object modification during construction gives "Modifying a const object is not allowed in a constant expression"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115900 --- Comment #10 from Valentin Tolmer --- Thanks a lot, that was fast!

[Bug c++/115900] New: [14 Regression] constexpr object modification during construction gives "Modifying a const object is not allowed in a constant expression"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115900 Bug ID: 115900 Summary: [14 Regression] constexpr object modification during construction gives "Modifying a const object is not allowed in a constant expression" Product: