Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(460)

Issue 4627087: [pph] Fix global variable assembly ordering (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
12 years, 10 months ago by Gabriel Charette
Modified:
12 years, 9 months ago
CC:
gcc-patches_gcc.gnu.org
Visibility:
Public.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+3 lines, -14 lines) Patch
M gcc/cp/pph-streamer-in.c View 1 chunk +3 lines, -0 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/c120060625-1.cc View 1 chunk +0 lines, -1 line 0 comments Download
M gcc/testsuite/g++.dg/pph/c1struct.cc View 1 chunk +0 lines, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/c1variables.cc View 1 chunk +0 lines, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/c1varorder.cc View 1 chunk +0 lines, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/c2builtin1.cc View 1 chunk +0 lines, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/c2builtin2.cc View 1 chunk +0 lines, -1 line 0 comments Download
M gcc/testsuite/g++.dg/pph/x1struct2.cc View 1 chunk +0 lines, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/x1variables.cc View 1 chunk +0 lines, -2 lines 0 comments Download

Messages

Total messages: 2
Gabriel Charette
As variables are discovered (while parsing the header) they are added to the varpool and ...
12 years, 10 months ago (2011-07-02 01:35:06 UTC) #1
Diego Novillo
12 years, 10 months ago (2011-07-04 16:49:22 UTC) #2
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.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b