On Fri, Sep 12, 2014 at 2:51 AM, Aldy Hernandez <al...@redhat.com> wrote:
> On 09/09/14 02:16, Richard Biener wrote:
>>
>> On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez <al...@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.
I'm sure you can come up with something ;)
>>
>>> 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...
Yeah, it looks very good. Let's cross fingers that it'll work ;)
Thanks,
Richard.
> As usual, thanks.
> Aldy
