https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:c6cc6d4741a880109c4e0e64d5a189687fb526f6 commit r15-498-gc6cc6d4741a880109c4e0e64d5a189687fb526f6 Author: Patrick Palka <ppa...@redhat.com> 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) <case MODOP_EXPR>: For a class assignment, consider the result type. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent32.C: New test. Reviewed-by: Jason Merrill <ja...@redhat.com>
