public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: optimization/7247: copy constructor missing when inlining enabled for i386
Date: Thu, 11 Jul 2002 14:06:00 -0000	[thread overview]
Message-ID: <20020711210602.3953.qmail@sources.redhat.com> (raw)

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

From: Jason Merrill <jason@redhat.com>
To: "H. J. Lu" <hjl@lucon.org>
Cc: gawrilow@math.tu-berlin.de, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: optimization/7247: copy constructor missing when inlining
 enabled for i386
Date: Thu, 11 Jul 2002 22:02:12 +0100

 >>>>> "H" == H J Lu <hjl@lucon.org> writes:
 
 > Jason, it looks like your patch doesn't catch this one.
 
 No, as the bug isn't related to the NRVO; this testcase doesn't have any
 returns which would be affected.  Rather, it seems to be a dependency
 tracking bug.  I can reproduce the bug by adding 'inline' to the definition
 of incidence_matrix and compiling with -O -fschedule-insns2.  Without
 -fschedule-insns2, the code leading up to the dump_op calls looks like
 
         movl    -96(%ebp), %eax
         movl    -92(%ebp), %edx
         movl    %eax, -52(%ebp)
         movl    %edx, -48(%ebp)
         leal    -96(%ebp), %eax
         movl    %eax, (%esp)
         call    pm::dump_op(pm::double_zero const&)
         leal    -52(%ebp), %eax
         movl    %eax, (%esp)
         call    pm::dump_op(pm::double_zero const&)
 
 so the epsilon value is properly copied before it is dumped.  But with
 scheduling, it looks like
 
         movl    -96(%ebp), %eax
         movl    %eax, -52(%ebp)
         leal    -96(%ebp), %eax
         movl    %eax, (%esp)
         call    pm::dump_op(pm::double_zero const&)
         leal    -52(%ebp), %eax
         movl    %eax, (%esp)
         call    pm::dump_op(pm::double_zero const&)
 
 Which suggests that the scheduler incorrectly decides that the second word
 wasn't used by the call and optimizes away the copy.  This bug, or a
 similar one, seems still to be present in the trunk, though to see it you
 also need to move the definition of the double_zero constructor outside the
 class, so it is not inlined.
 
 Jason


             reply	other threads:[~2002-07-11 21:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-11 14:06 Jason Merrill [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-10  2:16 Ewgenij Gawrilow
2002-07-09 12:07 nathan
2002-07-09 10:26 gawrilow

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=20020711210602.3953.qmail@sources.redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@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).