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.
case LABEL_DECL:
case FUNCTION_DECL:
case SSA_NAME:
+ case COMPOUND_LITERAL_EXPR:
case COMPONENT_REF:
case MEM_REF:
--- /dev/null
+/* { 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;
+}