From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Mark Mitchell Cc: dan@cgsoftware.com, wilson@cygnus.com, schwab@suse.de, gcc@gcc.gnu.org Subject: Re: Bootstrap failure of gcc-ss-20010409 in ia64 Date: Wed, 11 Apr 2001 20:24:00 -0000 Message-id: References: <200104111947.MAA23080@wilson.cygnus.com> <20010411174320Q.mitchell@codesourcery.com> <20010411183411J.mitchell@codesourcery.com> X-SW-Source: 2001-04/msg00518.html Content-type: multipart/mixed; boundary="----------=_1583532965-674-14" This is a multi-part message in MIME format... ------------=_1583532965-674-14 Content-length: 2217 Mark Mitchell 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. > ------------=_1583532965-674-14 Content-Type: text/x-diff; charset=us-ascii; name="attrdiff" Content-Disposition: inline; filename="attrdiff" Content-Transfer-Encoding: base64 Content-Length: 1188 SW5kZXg6IGR3YXJmMm91dC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNT IGZpbGU6IC9jdnMvZ2NjL2VnY3MvZ2NjL2R3YXJmMm91dC5jLHYKcmV0cmll dmluZyByZXZpc2lvbiAxLjI2MgpkaWZmIC1jIC0zIC1wIC13IC1CIC1iIC1y MS4yNjIgZHdhcmYyb3V0LmMKKioqIGR3YXJmMm91dC5jCTIwMDEvMDQvMDUg MDE6NDM6MTcJMS4yNjIKLS0tIGR3YXJmMm91dC5jCTIwMDEvMDQvMTIgMDM6 MTM6MTcKKioqKioqKioqKioqKioqIGFkZF9hYnN0cmFjdF9vcmlnaW5fYXR0 cmlidXRlIChkaWUsIG9yaWcKKioqIDg1MzcsODU0NSAqKioqCi0tLSA4NTMx LDg1NTMgLS0tLQogICAgICB9CiAgCiAgICBpZiAoREVDTF9QIChvcmlnaW4p KQorICAgICB7CiAgICAgIG9yaWdpbl9kaWUgPSBsb29rdXBfZGVjbF9kaWUg KG9yaWdpbik7CisgICAgIGlmIChvcmlnaW5fZGllID09IE5VTEwpCisgICAg ICAgeworIAlnZW5fZGVjbF9kaWUgKG9yaWdpbiwgZGllLT5kaWVfcGFyZW50 KTsKKyAJb3JpZ2luX2RpZSA9IGxvb2t1cF9kZWNsX2RpZSAob3JpZ2luKTsK KyAgICAgICB9CisgICAgIH0KICAgIGVsc2UgaWYgKFRZUEVfUCAob3JpZ2lu KSkKKyAgICAgeworICAgICAgIG9yaWdpbl9kaWUgPSBsb29rdXBfdHlwZV9k aWUgKG9yaWdpbik7CisgICAgICAgaWYgKG9yaWdpbl9kaWUgPT0gTlVMTCkK KyAJeworIAkgIGdlbl90eXBlX2RpZSAob3JpZ2luLCBkaWUtPmRpZV9wYXJl bnQpOwogIAkgIG9yaWdpbl9kaWUgPSBsb29rdXBfdHlwZV9kaWUgKG9yaWdp bik7CisgCX0KKyAgICAgfQogICAgCiAgICBpZiAob3JpZ2luX2RpZSA9PSBO VUxMKQogICAgICBhYm9ydCAoKTsK ------------=_1583532965-674-14--