From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53868 invoked by alias); 30 Jan 2018 17:59:06 -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 53858 invoked by uid 89); 30 Jan 2018 17:59:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,KAM_ASCII_DIVIDERS,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=stands, consumers, views, consumer X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Jan 2018 17:59:04 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A06B15BEBA; Tue, 30 Jan 2018 17:59:03 +0000 (UTC) Received: from freie.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B8E8660BE3; Tue, 30 Jan 2018 17:58:56 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by freie.home (8.15.2/8.15.2) with ESMTP id w0UHwjRu014107; Tue, 30 Jan 2018 15:58:45 -0200 From: Alexandre Oliva To: Jakub Jelinek Cc: Jason Merrill , Jeff Law , Richard Biener , gcc-patches Subject: Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views References: <20171110023448.28164-7-aoliva@redhat.com> <7d731476-256b-28c3-69fe-e28c116281d1@redhat.com> <20180124170848.GF2063@tucnak> <20180126145603.GY2063@tucnak> Date: Tue, 30 Jan 2018 18:40:00 -0000 In-Reply-To: <20180126145603.GY2063@tucnak> (Jakub Jelinek's message of "Fri, 26 Jan 2018 15:56:03 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-01/txt/msg02372.txt.bz2 On Jan 26, 2018, Jakub Jelinek wrote: > Having to tweak debug info consumers so that they treat DW_LLE_* of 9 > one way for .debug_loclist of version 5 and another way for .debug_loclist > of version 6 isn't a good idea. Maybe we don't have to do that. The reason I implemented the proposed format was to have a reference implementation, but since it's an extension to a non-extensible part of DWARF5, it's hard to justify consumer implementations for that. > Why don't you emit the DW_LLE_GNU_view_pair stuff in .debug_loclists > already with -gdwarf-5, if needed paired without some TU attribute that says > that views are emitted? Because that would make the loclists unreadable for any DWARF5-compliant consumer. > Haven't looked for it it in the coding standards, but it is something > I've been asked to do in my code by various reviewers over the years and > what I've been asking others in my patch reviews from others too. Thanks. It was the first (well, second; you'd requested similar changes another time before) I heard of that. I'm still unconvinced the way I used is not compliant, but I'll keep that in mind. Hopefully I won't run into someone who insists the other one (the one you reject) is the only correct one ;-) > I feel strongly about indenting stuff right, I'm with you on that, we just have different ideas about what "right" stands for ;-) > which if it wouldn't fit would be > return verylongcondition____________________________________ > && otherlongcondition__________________________________; > rather than > return verylongcondition____________________________________ > && otherlongcondition__________________________________; > or similar, it would surprise me if it is not in the coding standard. I agree neither of these two forms is correct. But it is my understanding that both of the following are correct: return (verylongcondition____________________________________ && otherlongcondition__________________________________); return verylongcondition____________________________________ && otherlongcondition__________________________________; The first, because the parenthesized expression is continued with indentation to match the parenthesis, the second because the return statement is continued with the correct indentation for the continuation of a statement. >> Personally, I don't see that line breaks before operators are only >> permitted when the operand that follows wouldn't fit; the standards are > Yes, you can break it, but why, it doesn't make the code more readable, > but less in this case. I thought it made it more readable, especially in the context of the patch. I guess this means we'll have to agree to disagree. > So, what is the reason not to emit the format you are proposing already with > -gdwarf-5, perhaps with some extra attribute on the TU (of course not when > -gstrict-dwarf)? See above. We don't want to create unreadable loclists for standard-compliant consumers, do we? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer