From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23359 invoked by alias); 14 Dec 2017 18:48:48 -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 23346 invoked by uid 89); 14 Dec 2017 18:48:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy= X-HELO: mail-qt0-f169.google.com Received: from mail-qt0-f169.google.com (HELO mail-qt0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Dec 2017 18:48:46 +0000 Received: by mail-qt0-f169.google.com with SMTP id f2so9208836qtj.4 for ; Thu, 14 Dec 2017 10:48:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CMHsx0pnbXSWYng5rDZUOdWk1BcZKFsltg/clmY7pIg=; b=nchMsGrKi65VaK6XehJ8lezfm0EZNCR0cZcqoQnw/gF3vrT+z9Hgrr0oMWya6DIg7r eZE3WamwHegZuVnWJJ809HtzdnfzATQqZHZ8/aPBPFa0xwfj2VeEBDTyGf1NaiUB2/FE TWIJUV2vRVj9YDC71UyqDVOBwBEGagIm/ywYBtZRMXxeCcqRBhAC6pD/JZKBbFW5FLES dsKZ+VVbznLQbCtsUbJlBXJM3iaZfp++bRWqyvw0HS2/frdR2j6A0vSECFLvVmBdqxfW Fk2J3D2/bu8oO5AQTzjPNo9+ieM/v+c2S0LOnaZ6UiyqG3Q8JNq7IM9Gq7uh+9cuaAZ2 BOig== X-Gm-Message-State: AKGB3mK4OG12EKKgzD7DWuodhGOAZjafk6m50PYOkL/a2s7WXuVFXbc/ NS5emOtccVDuvGK92O7WXBHo0Q== X-Google-Smtp-Source: ACJfBosVgCYIqcd1qdfCblKeP7483XjYNQ3HLZaG1grH25TbR3g94UDbDNgqJRnqye/wp8XFsJH6oQ== X-Received: by 10.200.51.20 with SMTP id t20mr18529079qta.150.1513277324661; Thu, 14 Dec 2017 10:48:44 -0800 (PST) Received: from [192.168.1.132] (209-6-90-240.s1774.c3-0.smr-ubr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.90.240]) by smtp.gmail.com with ESMTPSA id u43sm2990360qtj.54.2017.12.14.10.48.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 10:48:43 -0800 (PST) Subject: Re: [PR59319] output friends in debug info To: Alexandre Oliva Cc: Richard Biener , gcc-patches List , ccoutant@gmail.com References: From: Jason Merrill Message-ID: <040a1fc5-7d5b-b8ce-8d09-f7cf58f5f040@redhat.com> Date: Thu, 14 Dec 2017 18:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00944.txt.bz2 On 12/07/2017 04:04 PM, Alexandre Oliva wrote: > On Apr 7, 2017, Alexandre Oliva wrote: > >> On Mar 21, 2017, Alexandre Oliva wrote: >>> On Jan 27, 2017, Alexandre Oliva wrote: >>>> On Oct 19, 2016, Alexandre Oliva wrote: >>>>> On Sep 23, 2016, Alexandre Oliva wrote: >>>>>> On Aug 30, 2016, Alexandre Oliva wrote: >>>>>>> Handling non-template friends is kind of easy, [...] >>>>>> Ping? >>>>> Ping? (conflicts resolved, patch refreshed and retested) >>>> Ping? (trivial conflicts resolved) >>> Ping? https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html >> Ping? > Ping? (refreshed, retested) > > [PR59319] output friends in debug info > > Handling non-template friends is kind of easy, but it required a bit > of infrastructure in dwarf2out to avoid (i) forcing debug info for > unused types or functions: DW_TAG_friend DIEs are only emitted if > their DW_AT_friend DIE is emitted, and (ii) creating DIEs for such > types or functions just to have them discarded at the end. To this > end, I introduced a list (vec, actually) of types with friends, > processed at the end of the translation unit, and a list of > DW_TAG_friend DIEs that, when we're pruning unused types, reference > DIEs that are still not known to be used, revisited after we finish > deciding all other DIEs, so that we prune DIEs that would have > referenced pruned types or functions. > > Handling template friends turned out to be trickier: there's no > representation in DWARF for templates. I decided to give debuggers as > much information as possible, enumerating all specializations of > friend templates and outputting DW_TAG_friend DIEs referencing them as > well. I considered marking those as DW_AT_artificial, to indicate > they're not explicitly stated in the source code, but in the end we > decided that was not useful. The greatest challenge was to enumerate > all specializations of a template. It looked trivial at first, given > DECL_TEMPLATE_INSTANTIATIONS, but it won't list specializations of > class-scoped functions and of nested templates. For other templates, > I ended up writing code to look for specializations in the hashtables > of decl or type specializations. That's not exactly efficient, but it > gets the job done. How inefficient is it, exactly? I'm concerned about the impact on compile time of scanning the entire hash table for each friend declaration in a template instantiation. This sounds prohibitive for template-heavy code that uses friends. I wonder about changing register_specialization to fill out DECL_TEMPLATE_INSTANTIATIONS for more templates (even more than you already do). > + /* At DETAIL level 0, returns non-NULL if the named class TYPE has > + any friends, NULL otherwise. At higher detail levels, return a > + tree list with the friends of the named class type. Each > + TREE_VALUE contains one friend type or function decl. For > + non-template friends, TREE_PURPOSE is NULL. For template friend > + declarations, the returned entries depend on the DETAIL level. > + At level 1, and only at level 1, an entry with NULL TREE_VALUE > + and non-NULL TREE_PURPOSE will START the returned list to > + indicate the named class TYPE has at least one template friend. > + At level 2, each template friend will be in an entry with NULL > + TREE_VALUE, and with the TEMPLATE_DECL in TREE_PURPOSE. At level > + 3, instead of a NULL TREE_VALUE, we add one entry for each > + instantiation or specialization of the template that fits the > + template friend declaration, as long as there is at least one > + instantiation or specialization; if there isn't any, an entry > + with NULL TREE_VALUE is created. A negative detail level will > + omit non-template friends from the returned list. */ The calls I see only seem to use details 0 and 3, while I would expect level 3 to only be used with -g3. What is the purpose of the negative level? Jason