public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kenneth Zadeck <zadeck@naturalbridge.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: potiential problems with parm decls.
Date: Wed, 01 Aug 2007 17:34:00 -0000	[thread overview]
Message-ID: <46B0C40E.1060309@naturalbridge.com> (raw)
In-Reply-To: <46B0C17D.1020908@codesourcery.com>

Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>   
>> How are you (we) handling PARM_DECLS?
>> Honza has informed my that the PARM_DECLS in the function's
>> DECL_ARGUMENTS needs to be "==" to the set of PARM_DECLS accessed in the
>> function.
>>     
>
> The code I wrote doesn't set DECL_ARGUMENTS, on the theory that
> parameters are essentially local variables.  I think it would be best if
> you set these up because the only information I have is types, and that
> may not be enough.  But, if that's impractical, then I will see what I
> can do.
>
> Also as for:
>
>   
How do you represent the function_decls for the functions that do not
have bodies?  Do these have parm_decls in them, or only a list of
types?  If they have parm_decls, i could see a problem.  If they only
have types, then there is no problem with me doing the parm decls for
the functions i see.


>> Mark claims that everything on his end should work except for static
>> initializers so we may be ready for some larger scale testing as soon as
>> the above bug is tracked down.
>>     
>
> It's more that I don't know what else is broken, rather than that I
> think it's all perfect. :-)  I don't want to give the impression I think
> it's all in tip-top shape.
>   
That is certainly true for my code as well.
> Also, with respect to static initializers, I think I can make it work in
> the direction I started, but if you think it's easy to serialize
> initializers using your existing machinery, that might be an easier
> path.  How hard would it be to leverage your serialization code to put
> static initializers for variables in their own sections, so that the
> initializer for "i" would be in some ".lto.i" section in the same way
> that the body of "f" is in ".lto.f"?  I'm happy to work on this; I'm
> just looking for some guidance as to what you think about it.
>
> Thanks,
>
>   
My only concern here is that you said at the summit that these were not
in gimple.  If they are in gimple, then it should not be a big deal for
me to co-opt the existing machinery to put each of them in its own
section. 


Kenny

  reply	other threads:[~2007-08-01 17:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-01 14:16 Kenneth Zadeck
2007-08-01 17:23 ` Mark Mitchell
2007-08-01 17:34   ` Kenneth Zadeck [this message]
2007-08-02  0:43     ` Mark Mitchell
2007-08-02  1:10       ` Kenneth Zadeck
2007-08-02  2:50         ` Mark Mitchell
2007-08-01 20:44   ` [lto] PATCH COMMITTED " Kenneth Zadeck
2007-08-01 22:12     ` Tom Tromey
2007-08-01 22:36       ` Kenneth Zadeck
2007-08-02  1:06       ` [lto] PATCH COMMITTED to fix missing semicolons Kenneth Zadeck
2007-08-02  1:16         ` David Daney
2007-08-02  1:49           ` Andrew Pinski
2007-08-02 16:42             ` Kenneth Zadeck

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=46B0C40E.1060309@naturalbridge.com \
    --to=zadeck@naturalbridge.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mark@codesourcery.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).