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

2021-09-18 Thread Jeff Law via Gcc-patches




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  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  { };
+
+class GTY(()) string_concat_db
+{
+[...]
+  hash_map  *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 
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 88faa309e5d6c6171b957daaf2f800920869)
"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



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

2021-09-10 Thread Thomas Schwinge
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  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  { };
 +
 +class GTY(()) string_concat_db
 +{
 +[...]
 +  hash_map  *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
>From 9f1066fcb770397d6e791aa0594f067a755e2ed6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
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 88faa309e5d6c6171b957daaf2f800920869)
"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.
---
 gcc/input.c  | 9 +
 .../gcc.dg/plugin/diagnostic-test-string-literals-1.c| 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/input.c b/gcc/input.c
index 4b809862e02..dd753decfa0 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -1437,6 +1437,11 @@ string_concat_db::record_string_concatenation (int num, location_t *locs)
   gcc_assert (locs);
 
   location_t key_loc = get_key_loc (locs[0]);
+  /* We don't record data for 'RESERVED_LOCATION_P (key_loc)' key values:
+ any data now recorded under key 'key_loc' would be overwritten by a
+ subsequent call with the same key 'key_loc'.  */
+  if (RESERVED_LOCATION_P (key_loc))
+return;
 
   string_concat *concat