From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by sourceware.org (Postfix) with ESMTPS id DCC3E3947418 for ; Wed, 22 Apr 2020 14:24:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DCC3E3947418 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03MEMjRW092917; Wed, 22 Apr 2020 14:24:10 GMT Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 30jhyc1yna-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 14:24:10 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03MELdUF049618; Wed, 22 Apr 2020 14:22:09 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30gb3u0m9u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 14:22:09 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03MEM9To021879; Wed, 22 Apr 2020 14:22:09 GMT Received: from dhcp-10-154-147-211.vpn.oracle.com (/10.154.147.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Apr 2020 07:22:08 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent From: Qing Zhao In-Reply-To: Date: Wed, 22 Apr 2020 09:22:07 -0500 Cc: Qing Zhao via Gcc-patches , jakub@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: <8D4865D1-209A-491C-A265-E630E42406DE@ORACLE.COM> References: <616B2BE0-0C66-4736-90E5-ECAD1FA4F8AD@ORACLE.COM> <47B8948D-C9BA-41EC-B55B-AF8117E79C50@ORACLE.COM> To: Richard Sandiford , dmalcolm@redhat.com X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9598 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 adultscore=0 mlxlogscore=999 phishscore=0 suspectscore=3 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220114 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9598 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 mlxscore=0 clxscore=1011 suspectscore=3 phishscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220114 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_1, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY 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: Wed, 22 Apr 2020 14:24:16 -0000 Hi, Richard And Dave: Thanks a lot for the review and comments. > On Apr 21, 2020, at 1:46 PM, Richard Sandiford = wrote: >=20 > David Malcolm writes: >> On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote >>>=20 >>> Please add: >>>=20 >>> PR c/94230 Will do.=20 >>>=20 >>>> * 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.=20 >>>=20 >>> 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. Sounds reasonable to me, I will add that. >>>=20 >>>> @@ -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. >>>>=20 >>>> +@item -flocation-ranges >>>> +@opindex flocation-ranges >>>=20 >>> Normally the documented option should be the non-default one, >>> so -fno-... in this case. Okay.=20 >>>=20 >>>> +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. >>>=20 >>> 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". >>=20 >> Indeed. Okay, I see.=20 Providing a good documentation at the user level for this option might = be a challenge to me, I will try. -:) >>=20 >>> I know you're simply following the suggestion in the PR, sorry, >>=20 >> Sorry. I did put a caveat on the suggestion FWIW. >>=20 >>> but I wonder if the option should instead be: >>>=20 >>> -flarge-source-files >>>=20 >>> 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. >>=20 >> Another approach would be to go lower-level and introduce a param for >> this; something like "--param location-range-bits" defaulting to 5; = the >> user can set it to 0 to disable the range-bit optimization to deal = with >> bigger files, and it allows for experimentation without rebuilding = the >> compiler. >>=20 >> Again, I don't know if this is a good idea; I'm thinking aloud; I'm = not >> sure what the best direction here is. >=20 > The reason I like the -flarge-source-files (suggestion for better > names welcome) is that the user is giving user-level information and > letting the compiler decide how to deal with that. What the option > actually does can change with the implementation as necessary. >=20 > Potentially any user could hit the -Wmisleading-indent note, or could > hit the limit at which columns get dropped from diagnostics. So while > this option isn't going to be used all that often, it also doesn't = feel > like an option designed specifically for =E2=80=9Cpower users=E2=80=9D = who like to > experiment with compiler internals. Agreed, I prefer to use -flarge-source-files for this functionality.=20 Let me know if you have any other suggestions for this patch. Thanks. Qing >=20 > Thanks, > Richard