public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-5050] Generalize 'gcc/input.h:struct location_hash' Date: Tue, 9 Nov 2021 13:45:39 +0000 (GMT) [thread overview] Message-ID: <20211109134539.B61843858033@sourceware.org> (raw) https://gcc.gnu.org/g:088199e5d0fc0d54f48af0783a2630a773bbb387 commit r12-5050-g088199e5d0fc0d54f48af0783a2630a773bbb387 Author: Thomas Schwinge <thomas@codesourcery.com> Date: Tue Aug 31 23:30:25 2021 +0200 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'. Diff: --- gcc/input.h | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/gcc/input.h b/gcc/input.h index f7b08bdc444..bc44ba2507f 100644 --- a/gcc/input.h +++ b/gcc/input.h @@ -36,6 +36,28 @@ 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'. */ +/* Per PR103157 "'gengtype': 'typedef' causing infinite-recursion code to be + generated", don't use + typedef int_hash<location_t, UNKNOWN_LOCATION, BUILTINS_LOCATION> + location_hash; + here. + + It works for a single-use case, but when using a 'struct'-based variant + struct location_hash + : int_hash<location_t, UNKNOWN_LOCATION, BUILTINS_LOCATION> {}; + in more than one place, 'gengtype' generates duplicate functions (thus: + "error: redefinition of 'void gt_ggc_mx(location_hash&)'" etc.). + Attempting to mark that one up with GTY options, we run into a 'gengtype' + "parse error: expected '{', have '<'", which probably falls into category + "understanding of C++ is limited", as documented in 'gcc/doc/gty.texi'. + + 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); @@ -233,8 +255,6 @@ public: location_t * GTY ((atomic)) m_locs; }; -struct location_hash : int_hash <location_t, UNKNOWN_LOCATION> { }; - class GTY(()) string_concat_db { public:
reply other threads:[~2021-11-09 13:45 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20211109134539.B61843858033@sourceware.org \ --to=tschwinge@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /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: linkBe 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).