public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marek Polacek <polacek@redhat.com>
To: Jeff Law <law@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix middle-end/67133, part 1
Date: Fri, 14 Aug 2015 21:48:00 -0000	[thread overview]
Message-ID: <20150814204649.GC2093@redhat.com> (raw)
In-Reply-To: <55CE5054.5080400@redhat.com>

On Fri, Aug 14, 2015 at 02:32:20PM -0600, Jeff Law wrote:
> On 08/14/2015 01:58 PM, Marek Polacek wrote:
> >On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
> >>>Ok, I'll investigate and come back to y'all when/if I find something.
> >>Thanks.  I still regret using the TREE_TYPE as a way to chain elements in
> >>the free list:(  I didn't want to add another pointer field...
> >
> >It's actually plain to see what's happening.  Before isolate-paths we've got
> >
> >   <bb 2>:
> >   ...
> >   SR.5_10 = MEM[(const struct A &)0B];
> >   ...
> >   c_13 = C::size (&p1);
> >   ...
> >   if (_14 != 0)
> >     goto <bb 3>;
> >   else
> >     goto <bb 4>;
> >
> >   <bb 3>:
> >   fn1 (&D.2434.OutBufCur, &b, c_13);
> >
> >Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the
> >stmts in bb 2 and we find a null dereference, so insert_trap_and_remove_trailing_statements
> >comes in play and turns bb 2 into:
> >
> >   <bb 2>:
> >   ...
> >   SR.5_10 = MEM[(const struct A &)0B];
> >   __builtin_trap ();
> >
> >i.e. it removs the defining statement for c_13.  Then find_explicit_erroneous_behaviour
> >walks over bb 3, hits the fn1 (&D.2434.OutBufCur, &b, c_13); statement, and
> >ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE.
> >
> >The question now is what to do with that.  Skip SSA_NAME_IN_FREE_LIST?  That
> >sounds weird.  Note that we're going to remove bb 3 and bb 4 anyway...
> Jeez, looking at the code N years later, I feel like a complete idiot. Of
> course that's not going to work.
> 
> We certainly don't want to peek at SSA_NAME_IN_FREE_LIST.

Yeh, I thought as much.
 
> I wonder if we should be walking in backwards dominator order to avoid these
> effects.  Or maybe just ignoring any BB with no preds.  I'll ponder those
> over the weekend.

I suppose both ought to work.  Or at least theoretically we could run e.g.
cleanup_cfg to prune the IR after we've inserted trap and removed trailing
stmts so that it gets rid of unreachable bbs.  Would that make sense?

Anyway, if you think of how would you like to solve this I can take a crack
at it next week.

	Marek

  reply	other threads:[~2015-08-14 20:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 11:51 Marek Polacek
2015-08-14 13:19 ` Richard Biener
2015-08-14 13:36   ` Marek Polacek
2015-08-14 14:54     ` Jeff Law
2015-08-14 15:33       ` Marek Polacek
2015-08-14 15:39         ` Jeff Law
2015-08-14 20:12           ` Marek Polacek
2015-08-14 20:36             ` Jeff Law
2015-08-14 21:48               ` Marek Polacek [this message]
2015-08-17 17:47                 ` Jeff Law
2015-08-17 18:01                   ` Marek Polacek
2015-08-18  8:47                   ` Richard Biener
2015-08-18 20:09                     ` Marek Polacek
2015-08-19  9:54                       ` Richard Biener
2015-08-19 10:39                         ` Marek Polacek
2015-08-19 14:25                       ` Jeff Law
2015-08-20  9:05                       ` Andreas Schwab
2015-08-20 10:50                         ` Marek Polacek
2015-08-20 10:58                           ` Andreas Schwab
2015-08-20 16:42                           ` Jeff Law
2015-08-20 16:59                             ` Marek Polacek
2015-08-20 16:59                               ` Jeff Law
2015-08-20 17:02                               ` Marek Polacek
2015-08-20 17:11                                 ` Jeff Law
2015-08-23 10:54                         ` Jan-Benedict Glaw
2015-08-24 15:55                           ` Jeff Law
2015-08-24 16:15                             ` Marek Polacek

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=20150814204649.GC2093@redhat.com \
    --to=polacek@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=richard.guenther@gmail.com \
    /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).