From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23734 invoked by alias); 26 Jun 2014 08:48:32 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 23696 invoked by uid 48); 26 Jun 2014 08:48:29 -0000 From: "piotr5 at netscape dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/58051] No named return value optimization when returned object is implicitly converted Date: Thu, 26 Jun 2014 08:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: piotr5 at netscape dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg02072.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051 piotr5 at netscape dot net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr5 at netscape dot net --- Comment #1 from piotr5 at netscape dot net --- I have the same problem, it makes the r-value types tedious. however this is not a bug in gcc directly, it's a bug in stdc++1x specs omitting this special case and what should be done here. however, as a feature-request I suggest at least when accepting gcc extensions to the standard (or better yet check with the stdc++1x paper if this contradicts the standard), gcc should proceed as suggested in this bug-report. more concretely: if in the example given the return-value rval would stay alive after the return (for example it's static), then the current behaviour of gcc should be kept. if rval would become destroyed because of going out of scope through the return, then std::move() should implicitly be added by the compiler alike to syntactic sugar. alternatively one could write a software which checks all return statements for classes which can be r-value initialized and outputs a warning whenever the return statement doesn't come with std::move() around the returned value and the used variable is going out of scope. this functionality could also be added to whatever code-checker. but such a solution would only introduce yet another hassle for the programmer. to emphasize: the reason why this feature is important is because gcc doesn't automatically do garbage-collection. if return-statements copy and destroy some big class frequently, this creates many holes in memory, cluttering free space. so this kind of optimization is needed for both, speed and size...