Summary: | [4.2 Regression] post-increment of bool variable accepted as lvalue | ||
---|---|---|---|
Product: | gcc | Reporter: | Jorn Wolfgang Rennecke <amylaar> |
Component: | c++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andrew.stubbs, fang, gcc-bugs |
Priority: | P2 | Keywords: | accepts-invalid, patch |
Version: | 4.2.0 | ||
Target Milestone: | 4.3.0 | ||
URL: | http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01182.html | ||
Host: | Target: | ||
Build: | Known to work: | 3.4.0 3.0.4 3.3.3 3.2.3 4.3.0 | |
Known to fail: | 2.95.3 4.0.0 4.0.4 4.1.0 4.2.0 4.2.5 | Last reconfirmed: | 2007-08-06 14:45:32 |
Bug Depends on: | |||
Bug Blocks: | 29843 | ||
Attachments: | Patch for saying SAVE_EXPRs are not lvalues |
Description
Jorn Wolfgang Rennecke
2006-09-08 19:29:50 UTC
Confirmed, though in 3.0.4 to 3.4.0 we gave a weird error for this code: t.cc: In function `void f()': t.cc:5: error: assignment of read-only location I think the problem is that i++ is being replaced with "i = 1" and (i = 1) = 2; turns out to be legal C++. If we add to boolean_increment to build a NON_LVALUE_EXPR, we will get an error at least I hope. Yep that worked, testing the fix. Grrr my patch causes a rejects valid to happen. void f() { bool i = 0; ++i = 6; } Is valid code as preincrement is an lvalue. I have a better fix which does not regress on that valid code. Subject: Bug number PR C++/28989 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00532.html I have a new patch, for some reason we are looking through a SAVE_EXPR which is incorrect really. A SAVE_EXPR can never be a lvalue. Newest patch: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01182.html Created attachment 12335 [details]
Patch for saying SAVE_EXPRs are not lvalues
I looked into the history of lvalue_p and SAVE_EXPR has been there since day 1.
I cannot think of any corner cases because SAVE_EXPR is only ever used to make a rlvalue or at least that is what I understand it.
won't fix in GCC-4.0.x. Adjusting milestone. Fixed on the trunk. Subject: Bug 28989 Author: pinskia Date: Fri Aug 17 22:14:47 2007 New Revision: 127603 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127603 Log: 2007-08-17 Andrew Pinski <andrew_pinski@playstation.sony.com> PR c++/28989 * tree.c (lvalue_p_1 <case SAVE_EXPR>): SAVE_EXPRs are never lvalues. 2007-08-17 Andrew Pinski <andrew_pinski@playstation.sony.com> PR c++/28989 * g++.dg/expr/lval3.C: New test. * g++.dg/expr/lval4.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/lval3.C trunk/gcc/testsuite/g++.dg/expr/lval4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog I am not going to patch 4.2 and before for this, I will let someone else do it. Closing 4.1 branch. Closing 4.2 branch, fixed in 4.3. |