[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b3399b445ba7495b0479d43f2389e64d48de870e commit r14-10220-gb3399b445ba7495b0479d43f2389e64d48de870e Author: Patrick Palka Date: Tue May 14 22:55:16 2024 -0400 c++: lvalueness of non-dependent assignment expr [PR114994] r14-4111-g6e92a6a2a72d3b made us check non-dependent simple assignment expressions ahead of time and give them a type, as was already done for compound assignments. Unlike for compound assignments however, if a simple assignment resolves to an operator overload we represent it as a (typed) MODOP_EXPR instead of a CALL_EXPR to the selected overload. (I reckoned this was at worst a pessimization -- we'll just have to repeat overload resolution at instantiatiation time.) But this turns out to break the below testcase ultimately because MODOP_EXPR (of non-reference type) is always treated as an lvalue according to lvalue_kind, which is incorrect for the MODOP_EXPR representing x=42. We can fix this by representing such class assignment expressions as CALL_EXPRs as well, but this turns out to require some tweaking of our -Wparentheses warning logic and may introduce other fallout making it unsuitable for backporting. So this patch instead fixes lvalue_kind to consider the type of a MODOP_EXPR representing a class assignment. PR c++/114994 gcc/cp/ChangeLog: * tree.cc (lvalue_kind) : For a class assignment, consider the result type. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent32.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit c6cc6d4741a880109c4e0e64d5a189687fb526f6)
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 --- Comment #6 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c6cc6d4741a880109c4e0e64d5a189687fb526f6 commit r15-498-gc6cc6d4741a880109c4e0e64d5a189687fb526f6 Author: Patrick Palka Date: Tue May 14 22:55:16 2024 -0400 c++: lvalueness of non-dependent assignment expr [PR114994] r14-4111-g6e92a6a2a72d3b made us check non-dependent simple assignment expressions ahead of time and give them a type, as was already done for compound assignments. Unlike for compound assignments however, if a simple assignment resolves to an operator overload we represent it as a (typed) MODOP_EXPR instead of a CALL_EXPR to the selected overload. (I reckoned this was at worst a pessimization -- we'll just have to repeat overload resolution at instantiatiation time.) But this turns out to break the below testcase ultimately because MODOP_EXPR (of non-reference type) is always treated as an lvalue according to lvalue_kind, which is incorrect for the MODOP_EXPR representing x=42. We can fix this by representing such class assignment expressions as CALL_EXPRs as well, but this turns out to require some tweaking of our -Wparentheses warning logic and may introduce other fallout making it unsuitable for backporting. So this patch instead fixes lvalue_kind to consider the type of a MODOP_EXPR representing a class assignment. PR c++/114994 gcc/cp/ChangeLog: * tree.cc (lvalue_kind) : For a class assignment, consider the result type. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent32.C: New test. Reviewed-by: Jason Merrill
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Patrick Palka ---
A bit more reduced, demostrating it's not specific to UDLs:
struct udl_arg {
udl_arg operator=(int);
};
void g(udl_arg&&);
template
void h() {
udl_arg x;
g(x=42);
}
int main() {
h();
}
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
Andrew Pinski changed:
What|Removed |Added
Summary|fmtlib named argument |[14/15 Regression] fmtlib
|compiler error introduced |named argument compiler
|in g++-14.1 |error introduced in
||g++-14.1
Target Milestone|--- |14.2
Ever confirmed|0 |1
Keywords|needs-reduction |rejects-valid
Last reconfirmed||2024-05-08
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
```
typedef decltype(sizeof(1)) size_t;
struct udl_arg {
const char *str;
template auto operator=(T &) const -> int {}
};
constexpr auto operator""_a(const char *s, size_t) -> udl_arg
{
return {""};
}
template void h(T &&);
template
int test(int a)
{
h("t"_a="t");
}
auto t = test<1>(1);
