public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "fs dot open dot work at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/38958]  New: 'unused variable' warning emitted when extending the lifetime of a returned RAII type by holding a reference to const despite delayed destructor side-effects. [dtor]
Date: Sat, 24 Jan 2009 13:32:00 -0000	[thread overview]
Message-ID: <bug-38958-17222@http.gcc.gnu.org/bugzilla/> (raw)

Given a class C with destructor side-effects (as is common with RAII classes)
and a function fn which returns a rvalue of type C

   C fn()

the lifetime of the rvalue returned by fn() can be extended by holding a
reference to const C with

   C const& r = fn()

Although r is not explicitly referenced subsequently in the calling scope, upon
leaving scope the rvalue's dtor will be invoked.  So r is implicitly 'used'.

The assignment
   C c = fn()
has the same effect because of return value optimization.  Though
copy-semantics must be checked, the copy is elided.

G++ generates an 'unused variable' warning for 'r' but not for 'c'.

The following program demonstrates the warning.  The 'volatile int g' and
forced-inline noise is to compare the generated assembly to that generated when
the const& is removed.  The output in both cases is equivalent (identical at
-O2; the only difference in lower optimizations is an additional indirection
with the const& present).

----------------------------------
volatile int g; // for obvious side-effect visibility in generated assembly

struct Lock
{
   __attribute__((always_inline)) // for obvious side-effect visibility in
generated assembly

   ~Lock() { g = 0; }
};

Lock AcquireLock() { return Lock(); }

int main()
{
   Lock const& lock = AcquireLock();
   g = 1;
   g = 2;
   g = 3;
}
----------------------------------
In both cases, const& present and not present, the sequence of values moved
into g are 1,2,3,0 as desired.

This might be related to Bug 10416 but does not appear to duplicate it since
removing the const& removes the warning in this case.

This warning can be avoided by relying on return-value optimization and using
the assignment without the const& to generate equivalent code but I don't think
it should be emitted at all if it is not for the RVO version.  I would expect
it emitted for both or not emitted for either.


-- 
           Summary: 'unused variable' warning emitted when extending the
                    lifetime of a returned RAII type by holding a reference
                    to const despite delayed destructor side-effects. [dtor]
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fs dot open dot work at googlemail dot com
 GCC build triplet: i686-pc-linux-gnu, mingw
  GCC host triplet: i686-pc-linux-gnu, mingw
GCC target triplet: i686-pc-linux-gnu, mingw, arm-xscale-linux-gnu


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


             reply	other threads:[~2009-01-24 13:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-24 13:32 fs dot open dot work at googlemail dot com [this message]
2009-01-30 15:24 ` [Bug c++/38958] " bangerth at gmail dot com

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-38958-17222@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).