Mark Mitchell <mark@codesourcery.com> writes:

> Thanks for the analysis.
> 
> It's certainly the case that we now try to output an inlined instance
> of a function without having first shown the back end the un-inlined
> instance.  In my opinion, that's a good thing -- there's no need for
> it to know about anything except what we want it to know about.
> 
> However, the debug-generation routines need to be able to cope with
> that. 

Yes. In fact, the reason i knew about this was because i ran into a
similar problem working up a patch to use the correct virtual context for virtual
functions (since it's now DECL_VIRTUAL_CONTEXT, not DECL_CONTEXT). We
would end up seeing virtual function calls before seeing the type they
came from, go to lookup the type die, which wouldn't exist, and
segfault.  The correct fix, is, of course, to generate the die if it
doesn't exist, not segfault.

> If you can reproduce Jim's problem, maybe you could help him
> with the solution?  

The attached patch should actually fix it, even though i haven't been able to
reproduce it on my platforms.

I can't even fathom another explanation for this bug, given it doesn't
occur if you turn off inlining, this is the only abort in the area,
etc.

There are probably a few other places like this case, that need to be
fixed in the same way (IE it's likely you may see a similar type of
abort or a segfault because of a null value passed somewhere that
originated from a lookup of a die or decl)

A lot of things don't bother to check if the lookup_{decl,type_die}
failed.  At least add_abstract_origin was checking the return value
and aborting.

(add_pure_or_virtual_attribute does the same thing when you give it
the correct virtual context sometimes,because without checking,
it just passes the result along to anothner function, which promptly
crashes trying to deref a null pointer
it segfaults in the same type of situation, when you hit a type you
haven't hit in the "normal way" first.)
> I've asked him privately to look into it as
> quickly as possible -- as a favor to me, the bug-causer -- since it
> does apparently affect GCC 3.0 bootstraps on some targets.  If you
> were willing to help, that would be great.
>