[PATCH 2/4] allow poisoning input_location in ranges it should not be used

David Malcolm dmalcolm@redhat.com
Wed Jun 30 15:13:23 GMT 2021


On Wed, 2021-06-30 at 01:35 -0400, Trevor Saunders wrote:
> This makes it possible to assert if input_location is used during the
> lifetime
> of a scope.  This will allow us to find places that currently use it
> within a
> function and its callees, or prevent adding uses within the lifetime
> of a
> function after all existing uses are removed.
> 
> bootstrapped and regtested on x86_64-linux-gnu, ok?
> 
> Trev

[...snip...]

> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> index d58586f2526..3f68d1d79eb 100644
> --- a/gcc/diagnostic.c
> +++ b/gcc/diagnostic.c
> @@ -1835,7 +1835,7 @@ internal_error (const char *gmsgid, ...)
>    auto_diagnostic_group d;
>    va_list ap;
>    va_start (ap, gmsgid);
> -  rich_location richloc (line_table, input_location);
> +  rich_location richloc (line_table, UNKNOWN_LOCATION);
>    diagnostic_impl (&richloc, NULL, -1, gmsgid, &ap, DK_ICE);
>    va_end (ap);
>  

I actually make use of this in the analyzer: the analyzer sets
input_location to stmt->location when analyzing a given stmt - that
way, if the analyzer ICEs, the ICE is shown at the code construct that
crashed the analyzer.

This behavior is useful to me, and would be lost with the proposed
patch.

Is there a better way of doing what I'm doing?

Is the long-term goal of the patch kit to reduce our reliance on global
variables?  Are we ultimately still going to need a variable for "where
to show the ICE if gcc crashes"?  (perhaps stashing it in the
diagnostic_context???)

Hope this is constructive
Dave



More information about the Gcc-patches mailing list