public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/60306] [4.9 Regression] Incorrect devirtualization "pure virtual method called"
Date: Fri, 28 Feb 2014 20:32:00 -0000	[thread overview]
Message-ID: <bug-60306-4-SWfmKFpQWm@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-60306-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 32235
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32235&action=edit
Better WIP patch

Yep, ignoring the calls also surprised me. I spent some time trying to think of
and produce more evil testcases to this issue, but rest of Martin's reasoning
seems right. The code really just mixes up the case where it knows something on
all understood places with the case it knows something on all possible paths
through the code. It implements the first but wants the second.

I also tried to give up on all calls first. That makes the intraprocedural and
part of inter-procedural devirt to give up almost always. Except for trivial
cases that are handled by SCCVN you almost always have a call in a way, so
testsuite is not really happy about it.

Other option is to simply give up on recording anything when type change is
seen. This also fixes the bug, perhaps with less fallout.

Third option is to record if walk ever reached top of function and if it did
give up when type change is seen. This seems to be simple addition to ao
walker, we just need some interface for it.

Fourth option is to be smarter about the calls defining type that is something
I would like to do for next stage1, patch attached. It is ortoghonal to 1/2/3,
if we have it we will just understand more paths (and currently I punt if I see
some not understood path)

I can get some data on difference in between options 1,2,3 for mainline, or do
we just want to give up?


  parent reply	other threads:[~2014-02-28 20:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21 21:22 [Bug ipa/60306] New: " bredelin at ucla dot edu
2014-02-22 13:55 ` [Bug ipa/60306] [4.9 Regression] " rguenth at gcc dot gnu.org
2014-02-27  9:35 ` rguenth at gcc dot gnu.org
2014-02-28  1:17 ` hubicka at gcc dot gnu.org
2014-02-28  1:26 ` hubicka at gcc dot gnu.org
2014-02-28  5:10 ` hubicka at gcc dot gnu.org
2014-02-28  5:55 ` hubicka at gcc dot gnu.org
2014-02-28 12:32 ` rguenth at gcc dot gnu.org
2014-02-28 12:35 ` rguenth at gcc dot gnu.org
2014-02-28 20:32 ` hubicka at gcc dot gnu.org [this message]
2014-03-02  2:14 ` hubicka at gcc dot gnu.org
2014-03-02 20:52 ` hubicka at gcc dot gnu.org
2014-03-02 22:24 ` hubicka at gcc dot gnu.org

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-60306-4-SWfmKFpQWm@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).