From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-56888-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 19862 invoked by alias); 21 Jul 2002 21:51:59 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 19851 invoked from network); 21 Jul 2002 21:51:56 -0000
Received: from unknown (HELO soliton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 21 Jul 2002 21:51:56 -0000
Received: (from gdr@localhost)
	by soliton.integrable-solutions.net (8.11.6/8.11.6/SuSE Linux 0.5) id g6LLnSY03739;
	Sun, 21 Jul 2002 23:49:28 +0200
To: Mark Mitchell <mark@codesourcery.com>
Cc: Jason Merrill <jason@redhat.com>, Richard Henderson <rth@redhat.com>,
   "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [tree-ssa] Simplifying TARGET_EXPR
References: <27410000.1027287015@warlock.codesourcery.com>
From: Gabriel Dos Reis <gdr@codesourcery.com>
In-Reply-To: Mark Mitchell's message of "Sun, 21 Jul 2002 14:30:15 -0700"
Organization: CodeSourcery, LLC
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: Sun, 21 Jul 2002 18:04:00 -0000
Message-ID: <m3it387nvb.fsf@soliton.integrable-solutions.net>
X-SW-Source: 2002-07/txt/msg00977.txt.bz2

Mark Mitchell <mark@codesourcery.com> writes:

| --On Saturday, July 20, 2002 05:09:42 PM +0100 Jason Merrill 
| <jason@redhat.com> wrote:
| 
| > I'm interested in what y'all think about the second issue; it's something
| > I've run into previously when thinking about expanding NEW_EXPR.
| >
| > One problem with (b) is that using it requires the frontend to know about
| > passing by invisible reference.
| 
| I think (b) is by far better than (a).
| 
| (What I'd really like to see is the elimination of TARGET_EXPR in the
| front end before we reach the optimizers and code generators.  This
| might miss some opportunities for elimination of copy constructors,
| but, in practice, very few.  And, to be honest, I'm nervous about the
| compiler changing the number of objects constructed and destructed
| when optimization is enabled; that makes debugging optimized code
| that much harder.)

Do you think we should always elide copy-constructors by default,
unless explicitly told the contrary? 

-- Gaby