From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4F5E1386F82A for ; Tue, 21 Apr 2020 14:04:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F5E1386F82A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AB73B31B; Tue, 21 Apr 2020 07:04:43 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E9AB53F68F; Tue, 21 Apr 2020 07:04:42 -0700 (PDT) From: Richard Sandiford To: Qing Zhao via Gcc-patches Mail-Followup-To: Qing Zhao via Gcc-patches , dmalcolm@redhat.com, jakub@redhat.com, Qing Zhao , richard.sandiford@arm.com Cc: dmalcolm@redhat.com, jakub@redhat.com, Qing Zhao Subject: Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent References: <616B2BE0-0C66-4736-90E5-ECAD1FA4F8AD@ORACLE.COM> <47B8948D-C9BA-41EC-B55B-AF8117E79C50@ORACLE.COM> Date: Tue, 21 Apr 2020 15:04:41 +0100 In-Reply-To: <47B8948D-C9BA-41EC-B55B-AF8117E79C50@ORACLE.COM> (Qing Zhao via Gcc-patches's message of "Wed, 8 Apr 2020 14:39:22 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-16.5 required=5.0 tests=BAYES_00, GIT_PATCH_1, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 14:04:45 -0000 Qing Zhao via Gcc-patches writes: > Hi, > > Please take a look at the attached patch and let me know your comments. > > Thanks. > > Qing Acting as a reviewer of last resort since this isn't really my area, but FWIW, I agree losing column tracking at the current limit is a genuine regression and should be fixed for GCC 10. > gcc/ChangeLog: > > 2020-04-03 qing zhao > Please add: PR c/94230 > * common.opt: Add -flocation-ranges. > * doc/invoke.texi: Document it. > * toplev.c (process_options): set line_table->default_range_bits > to 0 when flag_location_ranges is false. I think it would be worth adding a hint to use the new option to get_visual_column, when warning about column tracking being disabled. This should probably be a second inform(), immediately after the current one. > @@ -14151,6 +14151,13 @@ This option may be useful in conjunction with the @option{-B} or > perform additional processing of the program source between > normal preprocessing and compilation. > > +@item -flocation-ranges > +@opindex flocation-ranges Normally the documented option should be the non-default one, so -fno-... in this case. > +Enable range tracking when recording source locations. > +By default, GCC enables range tracking when recording source locations. > +If disable range tracking by -fno-location-ranges, more location space > +will be saved for column tracking. My understanding is that the patch doesn't actually disable location-range tracking, but simply uses a less efficient form for *all* ranges, rather than only using the less efficient form for ranges that aren't "caret at start, length < 64 chars". I know you're simply following the suggestion in the PR, sorry, but I wonder if the option should instead be: -flarge-source-files since that seems like a more user-facing concept. The option would tell GCC that the source files are likely to be very large and that GCC should adapt accordingly. In particular, the option makes GCC cope with more source lines at the expense of slowing down compilation and using more memory. Thanks, Richard