public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Richard Henderson <rth@redhat.com>
Cc: Laurent GUERBY <laurent@guerby.net>,
	Chris Douty <Chris_Douty@ampex.com>,
	 gcc@gcc.gnu.org
Subject: Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
Date: Sun, 21 Aug 2005 02:33:00 -0000	[thread overview]
Message-ID: <1124591601.6453.36.camel@linux.site> (raw)
In-Reply-To: <20050821021550.GA14093@redhat.com>

On Sat, 2005-08-20 at 19:15 -0700, Richard Henderson wrote:
> On Fri, Aug 19, 2005 at 09:34:35PM -0400, Daniel Berlin wrote:
> > But for general IPA working on the cgraph + GIMPLE level, as is what is
> > happening here, I think we really need to do something about static
> > variable initializers so they are in GIMPLE.
> 
> No.  How could that possibly be?
>  We can't execute code for static
> variable initializers, so how can we gimplify?
What do you mean by this, exactly?

> 
> > Or do you have another idea?
> 
> You didn't say why analyze_expr was wrong.  I still think it's right.

Because analyze_expr doesn't give us any of the info we want.

The call that was failing in our case was a get_base_var of an
ADDR_EXPR<CONSTRUCTOR> in a static variable initial, called from static
variable address taken analysis.

analyze_expr would not help here.

The docs for analyze_expr says:

      This function is responsible for lowering tree nodes not
understood by
      generic code into understandable ones or alternatively marking
      callgraph and varpool nodes referenced by the as needed.

It's the "alternatively" part that makes it useless.

cxx_callgraph_analyze_expr, an implementation of this hook, simply marks
a bunch of varpool nodes as "used" (and it doesn't even tell us which
ones).

We don't care to know whether or not it should be marked used.
We want to know what's actually in the trees on the initializer them so
we can do analysis.

IE if we have something very funky like:

static int c;
static int d;
static struct foo *a = &{&c, &d};

(and if you look, andrew found a case where we are producing
&<constructor>, so this is a possibility, AFAICT)

In the above case, we need to see the &c, &d part.
How does analyze_expr help us here?

> 
> r~


  reply	other threads:[~2005-08-21  2:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-19 22:17 Chris Douty
2005-08-19 22:37 ` Laurent GUERBY
2005-08-19 22:44   ` Laurent GUERBY
2005-08-20  1:34     ` Daniel Berlin
2005-08-21  2:16       ` Richard Henderson
2005-08-21  2:33         ` Daniel Berlin [this message]
2005-08-22  2:45           ` Richard Henderson
2005-08-22  2:48             ` Andrew Pinski
2005-08-22  3:32             ` Daniel Berlin
2005-08-22  4:27               ` Richard Henderson
2005-08-22 11:38 Richard Kenner

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=1124591601.6453.36.camel@linux.site \
    --to=dberlin@dberlin.org \
    --cc=Chris_Douty@ampex.com \
    --cc=gcc@gcc.gnu.org \
    --cc=laurent@guerby.net \
    --cc=rth@redhat.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).