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
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 treegraph
Reported: 2006-09-08 19:29 UTC by Jorn Wolfgang Rennecke
Modified: 2009-03-30 17:04 UTC (History)
3 users (show)

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

Patch for saying SAVE_EXPRs are not lvalues (432 bytes, patch)
2006-09-27 06:56 UTC, Andrew Pinski
Details | Diff

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
  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.
  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:
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
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

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.


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.