public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Alan Lawrence <alan.lawrence@arm.com>, gcc-patches@gcc.gnu.org
Cc: rguenther@suse.de, jakub@redhat.com
Subject: Re: [PATCH] Empty redirect_edge_var_map after each pass and function
Date: Tue, 01 Dec 2015 22:38:00 -0000	[thread overview]
Message-ID: <565E2174.3030607@redhat.com> (raw)
In-Reply-To: <1448994839-10665-1-git-send-email-alan.lawrence@arm.com>

On 12/01/2015 11:33 AM, Alan Lawrence wrote:
>
> I was not able to reduce the testcase below about 30k characters, with e.g.
> #define T_VOID 0
> .... T_VOID ....
> producing the ICE, but manually changing to
> .... 0 ....
> preventing the ICE; as did running the preprocessor as a separate step, or a
> wide variety of options (e.g. -fdump-tree-alias).
Which is almost always an indication that there's a memory corruption, 
or uninitialized memory read or something similar.


>
> In the end I traced this to loop_unswitch reading stale values from the edge
> redirect map, which is keyed on 'edge' (a pointer to struct edge_def); the map
> entries had been left there by pass_dominator (on a different function), and by
> "chance" the edge *pointers* were the same as to some current edge_defs (even
> though they pointed to structures created by different allocations, the first
> of which had since been freed). Hence the fragility of the testcase and
> environment.
Right.  So the question I have is how/why did DOM leave anything in the 
map.   And if DOM is fixed to not leave stuff lying around, can we then 
assert that nothing is ever left in those maps between passes?  There's 
certainly no good reason I'm aware of why DOM would leave things in this 
state.

Jeff

  reply	other threads:[~2015-12-01 22:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 18:34 Alan Lawrence
2015-12-01 22:38 ` Jeff Law [this message]
2015-12-02  8:33   ` Richard Biener
2015-12-02 14:14     ` Jeff Law
2015-12-03 12:49       ` Alan Lawrence
2015-12-03 12:58         ` Richard Biener
2015-12-03 13:07           ` Richard Biener
2015-12-03 14:49           ` Alan Lawrence
2015-12-03 14:56             ` Richard Biener
2015-12-02  8:36 ` Richard Biener
2015-12-02 14:15   ` Jeff Law

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=565E2174.3030607@redhat.com \
    --to=law@redhat.com \
    --cc=alan.lawrence@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    /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).