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