public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: dmalcolm@redhat.com,  jakub@redhat.com,
	 Qing Zhao <QING.ZHAO@ORACLE.COM>
Subject: Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent
Date: Tue, 21 Apr 2020 15:04:41 +0100	[thread overview]
Message-ID: <mptv9ltgcjq.fsf@arm.com> (raw)
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")

Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org> 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  <qing.zhao@oracle.com>
>

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

  parent reply	other threads:[~2020-04-21 14:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 19:55 Qing Zhao
2020-04-08 19:39 ` PING " Qing Zhao
2020-04-15 20:30   ` Fwd: " Qing Zhao
2020-04-21 14:04   ` Richard Sandiford [this message]
2020-04-21 15:21     ` David Malcolm
2020-04-21 18:46       ` Richard Sandiford
2020-04-22 14:22         ` Qing Zhao
2020-04-23 14:41           ` [Version 2][PATCH][gcc][PR94230]provide " Qing Zhao
2020-04-23 18:27             ` Richard Sandiford
2020-04-23 19:52               ` Qing Zhao
2020-04-23 21:05               ` [Version 3][PATCH][gcc][PR94230]provide " Qing Zhao
2020-04-23 22:13                 ` David Malcolm
2020-04-24 22:22                   ` [Version 4][PATCH][gcc][PR94230]provide " Qing Zhao
2020-04-24 22:36                     ` David Malcolm
2020-04-27 14:23                       ` Qing Zhao
2020-05-06 18:40                   ` Committed [Version 3][PATCH][gcc][PR94230]provide " Qing Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mptv9ltgcjq.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=QING.ZHAO@ORACLE.COM \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).