This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [pph] Fix global variable assembly ordering (issue4627087)
- From: Diego Novillo <dnovillo at google dot com>
- To: Gabriel Charette <gchare at google dot com>
- Cc: reply at codereview dot appspotmail dot com, crowl at google dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 4 Jul 2011 12:49:19 -0400
- Subject: Re: [pph] Fix global variable assembly ordering (issue4627087)
- References: <20110702013502.8FD271C1CDF@gchare.mtv.corp.google.com>
On Fri, Jul 1, 2011 at 21:35, Gabriel Charette <gchare@google.com> wrote:
> As variables are discovered (while parsing the header) they are added to the varpool and their RTL is built.
>
> We do not stream, nor the varpool, nor the RTL (and I don't think we want to + that wouldn't
> work with multiple pph).
Right. Additionally, saving RTL makes the PPH target-dependent. We
don't want that.
>
> We want to rebuild the varpool when streaming the global variables of the pph in so as to
> redefine them in the varpool in the same order they would have been found in a regular
> #include style parse.
Right.
> I'm not sure whether "global variables, not externals" is specific enough or too broad (I can't reuse the caller
> of varpool_finalize_decl (rest_of_decl_compilation) to take care of this logic because it needs some parser
> state which we no longer have). I will create more tests next week with different orderings for functions,
> structs, etc. coming in from the pph.
Hm, I think we actually want to call rest_of_decl_compilation here.
This is also used from the LTO front end when reconstructing
variables. Your patch is in the right direction, though, so I've
applied it for now.
Diego.