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

Issue 4695048: [pph] Fix 3 asm differences (Closed)

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

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+75 lines, -33 lines) Patch
M gcc/cp/pph-streamer-in.c View 3 chunks +27 lines, -13 lines 0 comments Download
M gcc/cp/pph-streamer-out.c View 3 chunks +47 lines, -16 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc View 1 chunk +1 line, -1 line 0 comments Download
M gcc/testsuite/g++.dg/pph/c2pr36533.cc View 1 chunk +0 lines, -1 line 0 comments Download
M gcc/testsuite/g++.dg/pph/x2functions.cc View 1 chunk +0 lines, -2 lines 0 comments Download

Messages

Total messages: 4
Diego Novillo
This patch is a slight adaptation of Gab's fix to the order in which we ...
12 years, 9 months ago (2011-07-12 19:19:16 UTC) #1
Gabriel Charette
I like the modified implementation with VEC. We probably want pph_register_decl_in_symtab to be inline as ...
12 years, 9 months ago (2011-07-12 20:34:43 UTC) #2
Diego Novillo
On 11-07-12 16:34 , Gabriel Charette wrote: > We probably want pph_register_decl_in_symtab to be inline ...
12 years, 9 months ago (2011-07-12 22:26:03 UTC) #3
Gabriel Charette
12 years, 9 months ago (2011-07-12 23:47:43 UTC) #4
On Tue, Jul 12, 2011 at 3:25 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 11-07-12 16:34 , Gabriel Charette wrote:
>
>> We probably want pph_register_decl_in_symtab to be inline as it does
>> so little now.
>
> It doesn't really matter all that much.  Given that it's a static function,
> the compiler will inline it (or not) as an optimization.  The 'inline'
> keyword is more and more just a suggestion than an actual guarantee.
>

OK

>> Now that you simply chainon bindings, you probably want to nreverse
>> them before you chain them on (this way we will stream them in from
>> first->last as this pacth does (to alloc stuff in order), but them in
>> the chain we want them to be last->first as they should be if they had
>> been pushed as they are in the original parser).
>
> Perhaps, but first I want to make sure we really want to reverse them all.
>  Not every list is processed from back to front.
>

Ok, well for now in the code though they are inserted in the
current_bindings in the reverse order (names and namespaces for sure,
usings I'm not sure) then they were in the parser when originally
written out (I don't know if this causes problems...?)

Gab
Sign in to reply to this message.

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