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 <dmalc...@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 <tho...@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
