From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: wilson@cygnus.com Cc: gcc@gcc.gnu.org Subject: Re: Bootstrap failure of gcc-ss-20010409 in ia64 Date: Wed, 18 Apr 2001 13:49:00 -0000 Message-id: <20010418134948I.mitchell@codesourcery.com> References: <200104181941.MAA15831@wilson.cygnus.com> X-SW-Source: 2001-04/msg00888.html >>>>> "Jim" == Jim Wilson 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