Bug 28989 - [4.2 Regression] post-increment of bool variable accepted as lvalue
Summary: [4.2 Regression] post-increment of bool variable accepted as lvalue
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.0
: P2 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: accepts-invalid, patch
Depends on:
Blocks: 29843
  Show dependency tree / graph
 
Reported: 2006-09-08 19:29 UTC by Jorn Wolfgang Rennecke
Modified: 2009-03-30 17:04 UTC (History)
3 users (show)

See Also:
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

Attachments
Patch for saying SAVE_EXPRs are not lvalues (432 bytes, patch)
2006-09-27 06:56 UTC, Andrew Pinski 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2006-09-08 19:29:50 UTC 
void
f()
{
  bool i = 0;
  i++ = 6;
}
Comment 1 Andrew Pinski 2006-09-08 19:33:14 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
Comment 2 Andrew Pinski 2006-09-09 19:10:39 UTC 
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.
Comment 3 Andrew Pinski 2006-09-09 19:29:53 UTC 
Yep that worked, testing the fix.
Comment 4 Andrew Pinski 2006-09-09 23:33:54 UTC 
Grrr my patch causes a rejects valid to happen.
void
f()
{
  bool i = 0;
  ++i = 6;
}

Is valid code as preincrement is an lvalue.
Comment 5 Andrew Pinski 2006-09-10 00:20:58 UTC 
I have a better fix which does not regress on that valid code.
Comment 6 patchapp@dberlin.org 2006-09-14 01:34:39 UTC 
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
Comment 7 Andrew Pinski 2006-09-23 18:50:03 UTC 
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.
Comment 8 Andrew Pinski 2006-09-26 15:25:48 UTC 
Newest patch:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01182.html
Comment 9 Andrew Pinski 2006-09-27 06:56:07 UTC 
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.
Comment 10 Gabriel Dos Reis 2007-02-03 19:45:33 UTC 
won't fix in GCC-4.0.x.  Adjusting milestone.
Comment 11 Andrew Pinski 2007-08-17 22:15:03 UTC 
Fixed on the trunk.
Comment 12 Andrew Pinski 2007-08-17 22:15:12 UTC 
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
Comment 13 Andrew Pinski 2008-01-03 17:40:29 UTC 
I am not going to patch 4.2 and before for this, I will let someone else do it.
Comment 14 Joseph S. Myers 2008-07-04 21:30:00 UTC 
Closing 4.1 branch.
Comment 15 Joseph S. Myers 2009-03-30 17:04:41 UTC 
Closing 4.2 branch, fixed in 4.3.