public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Thomas Schwinge <thomas@codesourcery.com>,
	David Malcolm <dmalcolm@redhat.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PING] Re: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals
Date: Sat, 18 Sep 2021 23:52:46 -0600	[thread overview]
Message-ID: <e24d5beb-3af2-bd65-889c-960815057291@gmail.com> (raw)
In-Reply-To: <87r1dwuazb.fsf@euler.schwinge.homeip.net>



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


  parent reply	other threads:[~2021-09-19  5:52 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08 21:22 [PATCH] RFC: " David Malcolm
2016-07-20 19:38 ` David Malcolm
2016-07-21 16:38   ` Jeff Law
2016-07-26 16:43     ` [PATCH 1/3] (v2) " David Malcolm
2016-07-26 16:43       ` [PATCH 2/3] Use class substring_loc in c-format.c (PR c/52952) David Malcolm
2016-07-26 16:43       ` [PATCH 3/3] c-format.c: suggest the correct format string to use (PR c/64955) David Malcolm
2016-07-26 18:06       ` [PATCH 1/3] (v2) On-demand locations within string-literals Manuel López-Ibáñez
2016-07-27 14:30         ` David Malcolm
2016-07-27 22:42           ` Manuel López-Ibáñez
2016-07-28 20:12             ` David Malcolm
2016-07-28 20:38               ` Martin Sebor
2016-07-28 21:17                 ` Martin Sebor
2016-07-29 12:37                   ` David Malcolm
2016-07-29 14:22                     ` Martin Sebor
2016-07-29 14:46                       ` David Malcolm
2016-07-29 15:26                         ` David Malcolm
2016-07-29 16:54                           ` Manuel López-Ibáñez
2016-07-29 17:27                             ` David Malcolm
2016-07-30  1:18                               ` Manuel López-Ibáñez
2016-08-03 15:56                               ` Jeff Law
2016-08-01 21:13                   ` Joseph Myers
2016-07-29 21:42       ` Joseph Myers
2016-07-30  1:16         ` David Malcolm
2016-08-03 15:17           ` [PATCH 1/4] selftest.h: Add ASSERT_TRUE_AT and ASSERT_FALSE_AT David Malcolm
2016-08-03 15:17             ` [PATCH 2/4] (v3) On-demand locations within string-literals David Malcolm
2016-08-04 17:38               ` Jeff Law
2016-08-04 19:21                 ` David Malcolm
2016-08-04 20:18                   ` Jeff Law
2016-08-05 18:17                     ` [Committed] [PATCH 2/4] (v4) " David Malcolm
2016-08-06  5:48                       ` Markus Trippelsdorf
2016-08-06  5:59                         ` Prathamesh Kulkarni
2016-08-06 18:10                           ` [committed] Fix crash in selftest::test_lexer_string_locations_ucn4 (PR bootstrap/72823) David Malcolm
2021-09-02 13:59                       ` [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals Thomas Schwinge
2021-09-02 19:09                         ` Thomas Schwinge
2021-09-03 16:33                           ` Thomas Schwinge
2021-09-10  7:48                             ` [PING] " Thomas Schwinge
2021-09-17 11:16                               ` [PING^2] " Thomas Schwinge
2021-09-30  6:47                                 ` [PING^3] Generalize 'gcc/input.h:struct location_hash' (was: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals) Thomas Schwinge
2021-10-17 22:33                                   ` Jeff Law
2021-11-09 13:48                                     ` Thomas Schwinge
2021-09-19  5:52                               ` Jeff Law [this message]
2016-08-03 15:17             ` [PATCH 3/4] Use class substring_loc in c-format.c (PR c/52952) David Malcolm
2016-08-04 18:09               ` Jeff Law
2016-08-04 19:25                 ` David Malcolm
2016-08-04 20:22                   ` Jeff Law
2016-08-06  0:56                     ` [PATCH] c-format.c: cleanup of check_format_info_main David Malcolm
2016-08-08 17:20                       ` Jeff Law
2016-08-08 20:16                 ` [PATCH 3/4] Use class substring_loc in c-format.c (PR c/52952) David Malcolm
2016-08-03 15:17             ` [PATCH 4/4] c-format.c: suggest the correct format string to use (PR c/64955) David Malcolm
2016-08-04 19:55               ` Jeff Law
2016-08-04 21:06                 ` David Malcolm
2016-08-03 16:06             ` [PATCH 1/4] selftest.h: Add ASSERT_TRUE_AT and ASSERT_FALSE_AT Jeff Law
2016-08-04 19:02               ` David Malcolm
2016-08-03 15:59         ` [PATCH 1/3] (v2) On-demand locations within string-literals Jeff Law
2016-08-04 14:27           ` David Malcolm
2016-08-04 17:37             ` Jeff Law
2016-07-23 21:36 ` [PATCH] RFC: " Martin Sebor
2016-07-24  0:37   ` David Malcolm
2016-08-23  3:25     ` Martin Sebor
2016-08-23 13:59       ` David Malcolm
2016-08-23 15:18         ` Martin Sebor

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=e24d5beb-3af2-bd65-889c-960815057291@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=thomas@codesourcery.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).