public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r9-10147] c-family: Initialize ridpointers for __int128 etc. [PR105186] Date: Wed, 11 May 2022 06:26:25 +0000 (GMT) [thread overview] Message-ID: <20220511062625.CCC663839802@sourceware.org> (raw) https://gcc.gnu.org/g:6547662a2afdac90311bcd286f87e98e6bec03d0 commit r9-10147-g6547662a2afdac90311bcd286f87e98e6bec03d0 Author: Jakub Jelinek <jakub@redhat.com> Date: Mon Apr 11 10:41:07 2022 +0200 c-family: Initialize ridpointers for __int128 etc. [PR105186] The following testcase ICEs with C++ and is incorrectly rejected with C. The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP directives etc., like: /* Save away the identifier that indicates which attribute this is. */ identifier = (token->type == CPP_KEYWORD) /* For keywords, use the canonical spelling, not the parsed identifier. */ ? ridpointers[(int) token->keyword] : id_token->u.value; identifier = canonicalize_attr_name (identifier); I've tried to change those to use ridpointers only if non-NULL and otherwise use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks patch. The following patch instead just initializes ridpointers for the __intNN keywords. It can't be done earlier before we record_builtin_type as there are 2 different spellings and if we initialize those ridpointers early, the second record_builtin_type fails miserably. 2022-04-11 Jakub Jelinek <jakub@redhat.com> PR c++/105186 * c-common.c (c_common_nodes_and_builtins): After registering __int%d and __int%d__ builtin types, initialize corresponding ridpointers entry. * c-c++-common/pr105186.c: New test. (cherry picked from commit 083e8e66d2e90992fa83a53bfc3553dfa91abda1) Diff: --- gcc/c-family/c-common.c | 3 +++ gcc/testsuite/c-c++-common/pr105186.c | 5 +++++ 2 files changed, 8 insertions(+) diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 880292f13e2..330f6074de4 100644 --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -4026,6 +4026,9 @@ c_common_nodes_and_builtins (void) sprintf (name, "__int%d", int_n_data[i].bitsize); record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), name, int_n_trees[i].signed_type); + ridpointers[RID_FIRST_INT_N + i] + = DECL_NAME (TYPE_NAME (int_n_trees[i].signed_type)); + sprintf (name, "__int%d unsigned", int_n_data[i].bitsize); record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type); } diff --git a/gcc/testsuite/c-c++-common/pr105186.c b/gcc/testsuite/c-c++-common/pr105186.c new file mode 100644 index 00000000000..86b61f36b3e --- /dev/null +++ b/gcc/testsuite/c-c++-common/pr105186.c @@ -0,0 +1,5 @@ +/* PR c++/105186 */ +/* { dg-do compile } */ + +__attribute__((__int128)) int i; /* { dg-warning "'__int128' attribute directive ignored" } */ +__attribute__((__int128__)) int j; /* { dg-warning "'int128' attribute directive ignored" } */
reply other threads:[~2022-05-11 6:26 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=20220511062625.CCC663839802@sourceware.org \ --to=jakub@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).