[PING] Re: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals

Message ID 87r1dwuazb.fsf@euler.schwinge.homeip.net
State Superseded
Headers show
Series
  • [PING] Re: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals
Related show

Commit Message

Thomas Schwinge Sept. 10, 2021, 7:48 a.m.
Hi!

Ping.  My patches again attached, for easy reference.


Grüße
 Thomas


On 2021-09-03T18:33:37+0200, I wrote:
> Hi!

>

> On 2021-09-02T21:09:54+0200, I wrote:

>> On 2021-09-02T15:59:14+0200, I wrote:

>>> On 2016-08-05T14:16:58-0400, David Malcolm <dmalcolm@redhat.com> wrote:

>>>> Committed to trunk as r239175; I'm attaching the final version of the

>>>> patch for reference.

>>>

>>> David, you've added here 'gcc/input.h:struct location_hash' (see quoted

>>> below), which will be useful elsewhere, so:

>>>

>>>> --- a/gcc/input.c

>>>> +++ b/gcc/input.c

>>>

>>>> +/* Internal function.  Canonicalize LOC into a form suitable for

>>>> +   use as a key within the database, stripping away macro expansion,

>>>> +   ad-hoc information, and range information, using the location of

>>>> +   the start of LOC within an ordinary linemap.  */

>>>> +

>>>> +location_t

>>>> +string_concat_db::get_key_loc (location_t loc)

>>>> +{

>>>> +  loc = linemap_resolve_location (line_table, loc, LRK_SPELLING_LOCATION,

>>>> +                             NULL);

>>>> +

>>>> +  loc = get_range_from_loc (line_table, loc).m_start;

>>>> +

>>>> +  return loc;

>>>> +}

>>>

>>> OK to push the attached

>>> "Harden 'gcc/input.c:string_concat_db::get_key_loc'"?  (This fell out of

>>> my analysis for development work elsewhere.)

>>

>> My suggested patch was:

>>

>>     --- a/gcc/input.c

>>     +++ b/gcc/input.c

>>     @@ -1483,6 +1483,9 @@ string_concat_db::get_key_loc (location_t loc)

>>

>>        loc = get_range_from_loc (line_table, loc).m_start;

>>

>>     +  /* Ascertain that 'loc' is valid as a key in 'm_table'.  */

>>     +  gcc_checking_assert (!RESERVED_LOCATION_P (loc));

>>     +

>>        return loc;

>>      }

>>

>> Uh, I should've looked at the correct test logs...  This change actually

>> does regress 'c-c++-common/substring-location-PR-87721.c' and

>> 'gcc.dg/plugin/diagnostic-test-string-literals-1.c': for these, we do see

>> 'BUILTINS_LOCATION' (via 'string_concat_db::record_string_concatenation').

>> Unless someone tell me that's unexpected (I'm completely lost in this

>> code...)

>

> I think I convinced myself that the current code doesn't have stable

> behavior, so...

>

>> I shall change/generalize my changes to provide both a

>> 'location_hash' only using 'UNKNOWN_LOCATION' as a spare value for

>> 'Empty' (as currently used here) and another variant additionally using

>> 'BUILTINS_LOCATION' as spare value for 'Deleted'.

>

> ... I didn't do this, but instead would like to push the attached

> "Don't record string concatenation data for 'RESERVED_LOCATION_P'"

> (replacing "Harden 'gcc/input.c:string_concat_db::get_key_loc'" as

> originally proposed).  OK?

>

>

> ... and then re:

>

>>>> --- a/gcc/input.h

>>>> +++ b/gcc/input.h

>>>

>>>> +struct location_hash : int_hash <location_t, UNKNOWN_LOCATION> { };

>>>> +

>>>> +class GTY(()) string_concat_db

>>>> +{

>>>> +[...]

>>>> +  hash_map <location_hash, string_concat *> *m_table;

>>>> +};

>>>

>>> OK to push the attached

>>> "Generalize 'gcc/input.h:struct location_hash'"?

>

> Attached again.

>

>

> Grüße

>  Thomas



-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Comments

Jeff Law via Gcc-patches Sept. 19, 2021, 5:52 a.m. | #1
On 9/10/2021 1:48 AM, Thomas Schwinge wrote:
> Hi!

>

> Ping.  My patches again attached, for easy reference.

>

>

> Grüße

>   Thomas

>

>

> On 2021-09-03T18:33:37+0200, I wrote:

>> Hi!

>>

>> On 2021-09-02T21:09:54+0200, I wrote:

>>> On 2021-09-02T15:59:14+0200, I wrote:

>>>> On 2016-08-05T14:16:58-0400, David Malcolm <dmalcolm@redhat.com> wrote:

>>>>> Committed to trunk as r239175; I'm attaching the final version of the

>>>>> patch for reference.

>>>> David, you've added here 'gcc/input.h:struct location_hash' (see quoted

>>>> below), which will be useful elsewhere, so:

>>>>

>>>>> --- a/gcc/input.c

>>>>> +++ b/gcc/input.c

>>>>> +/* Internal function.  Canonicalize LOC into a form suitable for

>>>>> +   use as a key within the database, stripping away macro expansion,

>>>>> +   ad-hoc information, and range information, using the location of

>>>>> +   the start of LOC within an ordinary linemap.  */

>>>>> +

>>>>> +location_t

>>>>> +string_concat_db::get_key_loc (location_t loc)

>>>>> +{

>>>>> +  loc = linemap_resolve_location (line_table, loc, LRK_SPELLING_LOCATION,

>>>>> +                             NULL);

>>>>> +

>>>>> +  loc = get_range_from_loc (line_table, loc).m_start;

>>>>> +

>>>>> +  return loc;

>>>>> +}

>>>> OK to push the attached

>>>> "Harden 'gcc/input.c:string_concat_db::get_key_loc'"?  (This fell out of

>>>> my analysis for development work elsewhere.)

>>> My suggested patch was:

>>>

>>>      --- a/gcc/input.c

>>>      +++ b/gcc/input.c

>>>      @@ -1483,6 +1483,9 @@ string_concat_db::get_key_loc (location_t loc)

>>>

>>>         loc = get_range_from_loc (line_table, loc).m_start;

>>>

>>>      +  /* Ascertain that 'loc' is valid as a key in 'm_table'.  */

>>>      +  gcc_checking_assert (!RESERVED_LOCATION_P (loc));

>>>      +

>>>         return loc;

>>>       }

>>>

>>> Uh, I should've looked at the correct test logs...  This change actually

>>> does regress 'c-c++-common/substring-location-PR-87721.c' and

>>> 'gcc.dg/plugin/diagnostic-test-string-literals-1.c': for these, we do see

>>> 'BUILTINS_LOCATION' (via 'string_concat_db::record_string_concatenation').

>>> Unless someone tell me that's unexpected (I'm completely lost in this

>>> code...)

>> I think I convinced myself that the current code doesn't have stable

>> behavior, so...

>>

>>> I shall change/generalize my changes to provide both a

>>> 'location_hash' only using 'UNKNOWN_LOCATION' as a spare value for

>>> 'Empty' (as currently used here) and another variant additionally using

>>> 'BUILTINS_LOCATION' as spare value for 'Deleted'.

>> ... I didn't do this, but instead would like to push the attached

>> "Don't record string concatenation data for 'RESERVED_LOCATION_P'"

>> (replacing "Harden 'gcc/input.c:string_concat_db::get_key_loc'" as

>> originally proposed).  OK?

>>

>>

>> ... and then re:

>>

>>>>> --- a/gcc/input.h

>>>>> +++ b/gcc/input.h

>>>>> +struct location_hash : int_hash <location_t, UNKNOWN_LOCATION> { };

>>>>> +

>>>>> +class GTY(()) string_concat_db

>>>>> +{

>>>>> +[...]

>>>>> +  hash_map <location_hash, string_concat *> *m_table;

>>>>> +};

>>>> OK to push the attached

>>>> "Generalize 'gcc/input.h:struct location_hash'"?

>> Attached again.

>>

>>

>> Grüße

>>   Thomas

>

> -----------------

> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

>

> 0001-Don-t-record-string-concatenation-data-for-RESERVED_.patch

>

>  From 9f1066fcb770397d6e791aa0594f067a755e2ed6 Mon Sep 17 00:00:00 2001

> From: Thomas Schwinge <thomas@codesourcery.com>

> Date: Fri, 3 Sep 2021 18:25:10 +0200

> Subject: [PATCH] Don't record string concatenation data for

>   'RESERVED_LOCATION_P'

>

> 'RESERVED_LOCATION_P' means 'UNKNOWN_LOCATION' or 'BUILTINS_LOCATION.

> We're using 'UNKNOWN_LOCATION' as a spare value for 'Empty', so should

> ascertain that we don't use it as a key additionally.  Similarly for

> 'BUILTINS_LOCATION' that we'd later like to use as a spare value for

> 'Deleted'.

>

> As discussed in the source code comment added, for these we didn't have

> stable behavior anyway.

>

> Follow-up to r239175 (commit 88fa5555a309e5d6c6171b957daaf2f800920869)

> "On-demand locations within string-literals".

>

> 	gcc/

> 	* input.c (string_concat_db::record_string_concatenation)

> 	(string_concat_db::get_string_concatenation): Skip for

> 	'RESERVED_LOCATION_P'.

> 	gcc/testsuite/

> 	* gcc.dg/plugin/diagnostic-test-string-literals-1.c: Adjust

> 	expected error diagnostics.

OK
jeff

Patch

From 349a3172f64db93ee98ea39b36489b702b6596ab Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue, 31 Aug 2021 23:30:25 +0200
Subject: [PATCH 2/2] Generalize 'gcc/input.h:struct location_hash'

This is currently only used here ('gcc/input.h:class string_concat_db'), but is
actually generally useful, so advertize it as such.

Per the rationale given, we may use 'BUILTINS_LOCATION' as spare value for
'Deleted', in addition to the existing use of 'UNKNOWN_LOCATION' as spare value
for 'Empty'.

	gcc/
	* input.h (location_hash): Use 'BUILTINS_LOCATION' as spare value
	for 'Deleted'.  Turn into a '#define'.
---
 gcc/input.h | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/gcc/input.h b/gcc/input.h
index e6881072c5f..46971a2684c 100644
--- a/gcc/input.h
+++ b/gcc/input.h
@@ -36,6 +36,25 @@  extern GTY(()) class line_maps *saved_line_table;
    both UNKNOWN_LOCATION and BUILTINS_LOCATION fit into that.  */
 STATIC_ASSERT (BUILTINS_LOCATION < RESERVED_LOCATION_COUNT);
 
+/* Hasher for 'location_t' values satisfying '!RESERVED_LOCATION_P', thus able
+   to use 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION' as spare values for
+   'Empty'/'Deleted'.  */
+/* If the following is used more than once, 'gengtype' generates duplicate
+   functions (thus: "error: redefinition of 'void gt_ggc_mx(location_hash&)'"
+   etc.):
+
+       struct location_hash
+         : int_hash<location_t, UNKNOWN_LOCATION, BUILTINS_LOCATION> {};
+
+   Likewise for this:
+
+       typedef int_hash<location_t, UNKNOWN_LOCATION, BUILTINS_LOCATION>
+         location_hash;
+
+   Thus, use a plain ol' '#define':
+*/
+#define location_hash int_hash<location_t, UNKNOWN_LOCATION, BUILTINS_LOCATION>
+
 extern bool is_location_from_builtin_token (location_t);
 extern expanded_location expand_location (location_t);
 
@@ -230,8 +249,6 @@  public:
   location_t * GTY ((atomic)) m_locs;
 };
 
-struct location_hash : int_hash <location_t, UNKNOWN_LOCATION> { };
-
 class GTY(()) string_concat_db
 {
  public:
-- 
2.33.0