Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> This particular problem with the debug info did not exist
    Jim> until you checked in a patch that turned off the RTL inliner.
    Jim> As such, it represents a regression, and regressions should
    Jim> be fixed.

That's fair.

    Jim> I see this as another part of the tree inliner that isn't
    Jim> finished yet.  The RTL inliner handled this correctly.  It is
    Jim> easy for the tree inliner to handle this correctly too, we
    Jim> just haven't written the code for it yet.  This should be
    Jim> done before the tree inliner permanently replaces the RTL
    Jim> inliner.

I guess I'm still not sure exactly what needs to be done.  Is all that
needs to be done:

 If the function for which we are about to generate code is 
 inline, then:

 - Copy the BLOCK tree.

 - Generate code.   

 - Restore the original BLOCK tree, throwing away the copy.

?

If so, you're correct that that isn't a particularly difficult task.
I can certainly code that up, given a test-case, and such.

I don't know if it's really that simple, or not.

    Jim> they don't interfere with bootstraps.  However, debug info
    Jim> support is important for maintaining gcc and other programs,
    Jim> and a lot of people have put a lot of hard work into making
    Jim> the debug info useful.  We should not lightly abandon that
    Jim> effort.

I agree completely.  

    Jim> large C++ EH/Unwind API patch.  The only testcase we have for
    Jim> this problem fails because of fake variables inserted by the
    Jim> C++ front end for EH purposes.  It is unclear if this bug
    Jim> will be triggered by any other testcases.

Interesting point.  It is likely that it could be -- the front-end
doesn't really do anything special with those variables -- but your
point that we don't know how often the bug will come up is
interesting.

    Jim> problem today.  I will check in a patch to punt on the
    Jim> branch, and then document the correct fix in dwarf2out.c on
    Jim> the trunk, or if it isn't too hard, I may just write the damn
    Jim> code myself.

Thank you, for the analysis, the commentary, and the fix.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com