public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mtewoodbury at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59193] Unused postfix operator temporaries
Date: Sat, 22 Feb 2014 02:03:00 -0000	[thread overview]
Message-ID: <bug-59193-4-ZHTOZ5Me7e@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-59193-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury <mtewoodbury at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #10 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
There is no VARIABLE, just a TEMPORARY r-value like  all the others that hold
intermediate results.

Also, the LANGUAGE semantics has the operator produce a result, an r-value,
that
has to be represented in some manner, that is, it has a store of some kind.
The machine code generated without optimization is required to put that result
into the store before incrementing the specified l-value. (sub-clause 6.2.5.4)
Optimization is allowed to, but not required to, remove such operations as long
as the change produces no detectable change in the program's results.

Now, stop misrepresenting the standard.  It makes your other pronouncements
less credible.

To go over this again, if a piece of code specifies a postfix operation
conceptually, the original value is stored somewhere.  That stored value is
then
discarded.   Those steps are extraneous and the code would be conceptually
cleaner without them.  As such, their present is a defect, a trivial defect,
but
still a defect.  Using the prefix operator in its place improves to code, again
trivially, but it does improve it.  Such changes may want to cite something as
justification for the change.  This report is such a justification.  Until all
such defects have been removed, it should stay open.


  parent reply	other threads:[~2014-02-22  2:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-59193-4@http.gcc.gnu.org/bugzilla/>
2013-11-19 16:41 ` joseph at codesourcery dot com
2013-11-20  0:59 ` pinskia at gcc dot gnu.org
2014-02-05  9:07 ` mpolacek at gcc dot gnu.org
2014-02-12 19:22 ` mtewoodbury at gmail dot com
2014-02-12 19:30 ` pinskia at gcc dot gnu.org
2014-02-19  6:15 ` mtewoodbury at gmail dot com
2014-02-19  9:58 ` pinskia at gcc dot gnu.org
2014-02-19 10:18 ` jakub at gcc dot gnu.org
2014-02-20  2:48 ` mtewoodbury at gmail dot com
2014-02-20  6:15 ` pinskia at gcc dot gnu.org
2014-02-22  2:03 ` mtewoodbury at gmail dot com [this message]
2014-02-22  4:19 ` pinskia at gcc dot gnu.org
2014-02-22 11:10 ` mtewoodbury at gmail dot com
2014-06-25 11:27 ` mpolacek at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-59193-4-ZHTOZ5Me7e@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).