The problem here is after r0-92187-g2ec5deb5c3146c, maybe_lvalue_p would
return false for compound literals which causes non_lvalue_loc not
to wrap the expression with a NON_LVALUE_EXPR unlike before when it
return true as it returns true for all language specific tree codes.
This fixes that oversight and fixes the testcase to have the cast as
a non-lvalue.
Committed to the trunk as obvious after a bootstrap/test on x86_64-linux-gnu.
PR c/84900
gcc/ChangeLog:
* fold-const.cc (maybe_lvalue_p): Treat COMPOUND_LITERAL_EXPR
as a lvalue.
gcc/testsuite/ChangeLog:
* gcc.dg/compound-literal-cast-lvalue-1.c: New test.
---
gcc/fold-const.cc | 1 +
gcc/testsuite/gcc.dg/compound-literal-cast-lvalue-1.c | 9 +++++++++
2 files changed, 10 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/compound-literal-cast-lvalue-1.c
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 02a24c5fe65..5b9982e3651 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -2646,6 +2646,7 @@ maybe_lvalue_p (const_tree x)
case LABEL_DECL:
case FUNCTION_DECL:
case SSA_NAME:
+ case COMPOUND_LITERAL_EXPR:
case COMPONENT_REF:
case MEM_REF:
diff --git a/gcc/testsuite/gcc.dg/compound-literal-cast-lvalue-1.c
b/gcc/testsuite/gcc.dg/compound-literal-cast-lvalue-1.c
new file mode 100644
index 00000000000..729bae24316
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/compound-literal-cast-lvalue-1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c99" } */
+/* PR c/84900; casts from compound literals
+ were not considered a non-lvalue. */
+
+int main() {
+ int *p = &(int) (int) {0}; /* { dg-error "lvalue" } */
+ return 0;
+}
--
2.31.1
