From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54867 invoked by alias); 8 May 2017 16:27:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 54733 invoked by uid 89); 8 May 2017 16:27:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=jasonredhatcom, jason@redhat.com, sk:jason@r, stake X-HELO: mail-io0-f179.google.com Received: from mail-io0-f179.google.com (HELO mail-io0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 May 2017 16:27:49 +0000 Received: by mail-io0-f179.google.com with SMTP id o12so25237594iod.3 for ; Mon, 08 May 2017 09:27:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aXdcE4HMe8pdHUSC6dFPw7N+74/ElF2ZiEMfOXUQMsA=; b=b+zHEcagQgiJcVaW9fuVZdON3d+149FBJwFmJ1NtV3GkfqPWl8oV8dj5yQijyeZrqm vrEAffyazIJbepIO5aLNLy09qoF8ZVP4rYupocrr7aSE/mn6NPMlubynddsJzF8Jxjje sBaFuGPCn4rxY1JsNXljbhJ3fY/oPYnhHLh2us8dV8c+7xWixyncrOcZ2LZWicHz5OME SkEPDifoUut488H7j0Hq3IhqjAORIq5TTBTsCF+wFsAXdSUi+wRfa/BA76E6rVmjuRL1 k1PXrKcAO+qAMomIfeKqHUia/imK08LG54tRowrWK9Lna8o1mJd1PhuySrbdFv76wkYi EZoQ== X-Gm-Message-State: AODbwcCQq7PWeGIjAUts51e+P+pliL/f8JqSuu8a8wEHJPWBuYgBGYDu 0yQIYsWsRjwAQPylK0SvX/qTHZ/t2jdR X-Received: by 10.107.25.203 with SMTP id 194mr8631310ioz.182.1494260869768; Mon, 08 May 2017 09:27:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.6.226 with HTTP; Mon, 8 May 2017 09:27:29 -0700 (PDT) In-Reply-To: References: <20170314122410.21497-1-derodat@adacore.com> From: Jason Merrill Date: Mon, 08 May 2017 16:41:00 -0000 Message-ID: Subject: Re: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining To: Pierre-Marie de Rodat Cc: gcc-patches List Content-Type: multipart/mixed; boundary=001a113fe2da58ac3b054f05b81c X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00567.txt.bz2 --001a113fe2da58ac3b054f05b81c Content-Type: text/plain; charset=UTF-8 Content-length: 3342 On Wed, May 3, 2017 at 3:22 PM, Jason Merrill wrote: > On Tue, Mar 14, 2017 at 8:24 AM, Pierre-Marie de Rodat > wrote: >> Hello, >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542 reports an ICE in >> dwarf2out.c for an Ada testcase built with optimization. >> >> This crash happens during the late generation pass because >> add_gnat_descriptive_type cannot find the type DIE corresponding to some >> descriptive type after having tried to generate it. This is because the >> DIE was generated during the early generation pass, but then pruned by >> the type pruning machinery. So why was it pruned? >> >> We are in a situation where we have cloned types (because of inlining, >> IIUC) whose TYPE_NAME have non-null DECL_ABSTRACT_ORIGIN attributes. As >> a consequence: >> >> * In modified_type_die, the "handle C typedef types" part calls >> gen_type_die on the cloned type. >> >> * gen_type_die matches a typedef variant, and then calls gen_decl_die >> on its TYPE_NAME, which will end up calling gen_typedef_die. >> >> * gen_typedef_die checks decl_ultimate_origin for this TYPE_DECL, and >> finds one, so it only adds a DW_AT_abstract_origin attribute to the >> DW_TAG_typedef DIE, but the cloned type itself does not get its own >> DIE. > > That seems like a bug; if gen_typedef_die is going to generate a DIE > for a cloned typedef, it needs to associate the type with the DIE. > >> * Back in modified_type_die, the call to lookup_type_die on the type >> passed to gen_type_die returns NULL. > >> In the end, whole type trees, i.e. the ones referenced by >> DECL_ABSTRACT_ORIGIN attributes, are never referenced from type pruning >> "roots" and are thus pruned. The descriptive type at stake here is one >> of them, hence the assertion failure. >> >> This patch attemps to fix that with what seems to be the most sensible >> thing to do in my opinion: updating the "handle C typedef types" part in >> modified_type_die to check decl_ultimate_origin before calling >> gen_type_die: if that function returns something not null, then we know >> that gen_type_die/gen_typedef_die will not generate a DIE for the input >> type, so we try to process the ultimate origin instead. > > This soundsn good; the DWARF standard says that we don't need to have > a die at all for the cloned typedef. > >> @@ -12496,6 +12496,18 @@ modified_type_die (tree type, int cv_quals, bool reverse, >> >> if (qualified_type == dtype) >> { >> + tree origin >> + = TYPE_NAME (qualified_type) == NULL >> + ? NULL >> + : decl_ultimate_origin (TYPE_NAME (qualified_type)); > > This is unnecessarily complicated; at this point we already know that > TYPE_NAME (qualified_type) is non-null and in the variable "name". > >> + /* Typedef variants that have an abstract origin don't get their own >> + type DIE (see gen_typedef_die), so fall back on the ultimate > > gen_typedef_die does create a DIE for them, it just doesn't do it > properly. But we could change gen_typedef_die to abort in that case, > making this comment correct. Something like this, which also avoids routinely creating DIEs for local typedefs that will only be pruned away later; this patch doesn't change the size of .debug_info in cc1plus. --001a113fe2da58ac3b054f05b81c Content-Type: text/plain; charset=US-ASCII; name="inline-static.diff" Content-Disposition: attachment; filename="inline-static.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j2gc8b9e0 Content-length: 1721 Y29tbWl0IDU2Y2NlMTExODFkMTI5NmU0M2NiNGQ2MDNmYzhlZmM2YWMyNTcw ZmEKQXV0aG9yOiBKYXNvbiBNZXJyaWxsIDxqYXNvbkByZWRoYXQuY29tPgpE YXRlOiAgIFRodSBNYXkgNCAxNTowMDo1MSAyMDE3IC0wNDAwCgogICAgaW5s aW5lLXN0YXRpYwoKZGlmZiAtLWdpdCBhL2djYy9kd2FyZjJvdXQuYyBiL2dj Yy9kd2FyZjJvdXQuYwppbmRleCA2Y2FmNTk4Li5iZjZhNjViIDEwMDY0NAot LS0gYS9nY2MvZHdhcmYyb3V0LmMKKysrIGIvZ2NjL2R3YXJmMm91dC5jCkBA IC0yNDM1NSw3ICsyNDM1NSw3IEBAIGdlbl90eXBlZGVmX2RpZSAodHJlZSBk ZWNsLCBkd19kaWVfcmVmIGNvbnRleHRfZGllKQogICB0eXBlX2RpZSA9IG5l d19kaWUgKERXX1RBR190eXBlZGVmLCBjb250ZXh0X2RpZSwgZGVjbCk7CiAg IG9yaWdpbiA9IGRlY2xfdWx0aW1hdGVfb3JpZ2luIChkZWNsKTsKICAgaWYg KG9yaWdpbiAhPSBOVUxMKQotICAgIGFkZF9hYnN0cmFjdF9vcmlnaW5fYXR0 cmlidXRlICh0eXBlX2RpZSwgb3JpZ2luKTsKKyAgICBnY2NfdW5yZWFjaGFi bGUgKCksIGFkZF9hYnN0cmFjdF9vcmlnaW5fYXR0cmlidXRlICh0eXBlX2Rp ZSwgb3JpZ2luKTsKICAgZWxzZQogICAgIHsKICAgICAgIHRyZWUgdHlwZSA9 IFRSRUVfVFlQRSAoZGVjbCk7CkBAIC0yNDg1OCw2ICsyNDg1OCwxNiBAQCBw cm9jZXNzX3Njb3BlX3ZhciAodHJlZSBzdG10LCB0cmVlIGRlY2wsIHRyZWUg b3JpZ2luLCBkd19kaWVfcmVmIGNvbnRleHRfZGllKQogICBlbHNlCiAgICAg ZGllID0gTlVMTDsKIAorICBpZiAoKG9yaWdpbiB8fCBERUNMX0FCU1RSQUNU X09SSUdJTiAoZGVjbCkpCisgICAgICAmJiAoVFJFRV9DT0RFIChkZWNsX29y X29yaWdpbikgPT0gVFlQRV9ERUNMCisJICB8fCAoVkFSX1AgKGRlY2xfb3Jf b3JpZ2luKSAmJiBUUkVFX1NUQVRJQyAoZGVjbF9vcl9vcmlnaW4pKSkpCisg ICAgeworICAgICAgb3JpZ2luID0gZGVjbF91bHRpbWF0ZV9vcmlnaW4gKGRl Y2xfb3Jfb3JpZ2luKTsKKyAgICAgIGlmIChkZWNsICYmIFZBUl9QIChkZWNs KSkKKwllcXVhdGVfZGVjbF9udW1iZXJfdG9fZGllIChkZWNsLCBsb29rdXBf ZGVjbF9kaWUgKG9yaWdpbikpOworICAgICAgcmV0dXJuOworICAgIH0KKwog ICBpZiAoZGllICE9IE5VTEwgJiYgZGllLT5kaWVfcGFyZW50ID09IE5VTEwp CiAgICAgYWRkX2NoaWxkX2RpZSAoY29udGV4dF9kaWUsIGRpZSk7CiAgIGVs c2UgaWYgKFRSRUVfQ09ERSAoZGVjbF9vcl9vcmlnaW4pID09IElNUE9SVEVE X0RFQ0wpCg== --001a113fe2da58ac3b054f05b81c--