From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-20288-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22968 invoked by alias); 10 Jul 2002 09:16:03 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 22949 invoked by uid 71); 10 Jul 2002 09:16:02 -0000
Date: Wed, 10 Jul 2002 02:16:00 -0000
Message-ID: <20020710091602.22947.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Ewgenij Gawrilow <gawrilow@math.TU-Berlin.DE>
Subject: Re: optimization/7247: copy constructor missing when inlining enabled for i386
Reply-To: Ewgenij Gawrilow <gawrilow@math.TU-Berlin.DE>
X-SW-Source: 2002-07/txt/msg00290.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR optimization/7247; it has been noted by GNATS.

From: Ewgenij Gawrilow <gawrilow@math.TU-Berlin.DE>
To: nathan@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org
Subject: Re: optimization/7247: copy constructor missing when inlining enabled for i386
Date: Wed, 10 Jul 2002 11:07:57 +0200

 >>>>> "nathan" == nathan  <nathan@gcc.gnu.org> writes:
 
     nathan> Synopsis: copy constructor missing when inlining enabled
     nathan> for i386
 
     nathan> If I understand you correctly, you are
     nathan> complaining that a copy ctor call is being optimized away.
     nathan> This is allowed, under [12.8]/15, even if the copy ctor
     nathan> has side-effects
 
 The class whose construction fails is defined in my test case
 as follows:
 
 struct double_zero {
    const double epsilon;
 
    double_zero(const double& epsilon_arg=1e-8) : epsilon(epsilon_arg) { }
 };
 
 One would expect from a copy constructor, especially from the implicit
 one, that it would copy the value of the instance variable
 "epsilon". I don't think this could fall under the definition of a side effect.
 
 Alternatively, if optimization according to the clause [12.8]/15 comes
 into effect here, as you mean, then it is the constructor
 double_zero(const double&) that is being forgotten. At any rate, the
 "epsilon" variable contains garbage after the construction, as shows up
 in the debugging output.
 
 Encouraged by such a quick response, I hope for a similarly quick fix :-)
 
 With best regards,
 Ewgenij Gawrilow