On 09/09/14 02:16, Richard Biener wrote:
> On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> On 09/05/14 02:00, Richard Biener wrote:

>> What I have in mind is:
>>
>> 1. Move the FE specific things that come before the call to
>> finalize_compilation_unit currently in each LANG_HOOKS_WRITE_GLOBALS, into
>> the FE proper (lang_hooks.parse_file).  This may or may not mean calling
>> {wrapup,check}_global_declarations directly from the FEs since some FE's
>> call these in a sufficiently different order to merit everyone doing their
>> own thing (not sure though).

Done.

>>
>> 2. Generate debug information by gathering the list of globals with
>> lang_hooks.decls.getdecls (??) and then doing
>> debug_hooks->early_global_decl() as discussed.
>
> Or move that also to lang_hooks.parse_file?  ISTR lang_hooks.decls.getdecls
> is sort of an "alternative" hook to write_global_declarations that is only
> used by the generic implementation of write_global_declarations.

Done.

>
> So if we move everything else but calling debug_hooks->early_global_decl ()
> out of the write_global_declarations langhook then we could indeed
> remove that hook and implement getdecls everywhere.
>
> I suppose one of the hooks should go in the end.
>
>> 2. Call finalize_compilation_unit() directly from compile_file().

Done.

>
> Great!
>
>> 3. Call some (new) hook for C++ stuff after finalize_compilation_unit (???).
>
> Or fix the C++ stuff to work properly in a symtab way?  I suppose as
> an intermediate step adding a new langhook for this on the branch is ok
> but I'd rather not get that merged into trunk.

Done.  For now I've called it 
LANG_HOOK_POST_COMPILATION_PARSING_CLEANUPS, and it is only applicable 
to C++, unless some other FE acts up in the process and needs similar 
massaging.

> Maybe Jason can help cleaning this up.

Jason's not much of a beer drinker AFAICT, so I'm trying to come up with 
a suitable bribe.

>
>> 4. FOR_EACH_DEFINED_SYMBOL (node)
>>       debug_hooks->late_global_decl (node->decl)
>>
>>     as suggested.

Done.

[Well... as DONE as a prototype can be :).  This is a work in progress, 
but I'd like y'all to peek at it, to make sure I'm not making obvious 
wrong turns that will have me rewriting code months from now, and hating 
you in the process.  And by you, I mean Jason *and* you.  I don't want 
anyone to feel left out by my frustration and anger.]

I drafted what I want Ada, Java, Fortran, and Go to look like (as well 
as the obvious C/C++ languages).

For C, guality.exp exhibits less failures than mainline.  I'm currently 
debugging inline virtual C++ destructors.  It seems the inliner can also 
call generate debugging info (debug_hooks->outlining_inline_function). 
The rest of the languages are tested as far as building jc1/f951/go1 
with no warnings :-))).

There are various cleanups and comments along the way.

Let me know if you're "mostly" OK with this, so I can push this to the 
branch and continue iterating with you incrementally.  It seems there 
will be no shortage of weird bugs in dwarf generation due to the fact 
that we stream early.  I'm hoping to start concentrating on those...

As usual, thanks.
Aldy