This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/45437] Loses reference during update
- From: "redi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Aug 2010 11:28:55 -0000
- Subject: [Bug c++/45437] Loses reference during update
- References: <bug-45437-6594@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #9 from redi at gcc dot gnu dot org 2010-08-29 11:28 -------
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1944 proposed the
changes to sequencing wording, revised in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2239.html
The new wording makes it clear that a compound assignment such as |= has this
sequence:
- evaluation of operands
- assignment
- evaluation of assignment expression i.e. evaluating result of (a|=b) for use
in another expression
However I don't think that affects this case.
The builtin |= operator is not a function (see 5p2) and does not obey the rules
of operand types of function calls, so it is not appropriate to describe the
effects in terms of
bool& c = a;
bool d = f();
operator|=(c, d)
The operand to the builtin |= is an lvalue expression, not a reference.
The new wording also makes it clear it is only evaluated once, before the
assignment. It is not specified whether evaluation of the left operand is
sequenced before evaluation of the right operand, therefore the compiler is
still permitted to evaluate sz.b (as false) then evaluate f(...) ( also false)
then perform the assignment of sz.b=(false|false)
Thus, invalid.
--
redi at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437