* [PATCH] c-family: Initialize ridpointers for __int128 etc. [PR105186]
@ 2022-04-08 7:29 Jakub Jelinek
2022-04-09 21:04 ` Marek Polacek
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2022-04-08 7:29 UTC (permalink / raw)
To: Joseph S. Myers, Marek Polacek, Jason Merrill; +Cc: gcc-patches
Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-04-08 Jakub Jelinek <jakub@redhat.com>
PR c++/105186
* c-common.cc (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.
--- gcc/c-family/c-common.cc.jj 2022-04-07 17:18:14.378883472 +0200
+++ gcc/c-family/c-common.cc 2022-04-07 17:21:07.950463695 +0200
@@ -4278,6 +4278,8 @@ 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);
--- gcc/testsuite/c-c++-common/pr105186.c.jj 2022-04-07 17:25:32.084781386 +0200
+++ gcc/testsuite/c-c++-common/pr105186.c 2022-04-07 17:25:13.736037189 +0200
@@ -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" } */
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] c-family: Initialize ridpointers for __int128 etc. [PR105186]
2022-04-08 7:29 [PATCH] c-family: Initialize ridpointers for __int128 etc. [PR105186] Jakub Jelinek
@ 2022-04-09 21:04 ` Marek Polacek
0 siblings, 0 replies; 2+ messages in thread
From: Marek Polacek @ 2022-04-09 21:04 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Joseph S. Myers, Jason Merrill, gcc-patches
On Fri, Apr 08, 2022 at 09:29:52AM +0200, Jakub Jelinek wrote:
> Hi!
>
> 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.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2022-04-08 Jakub Jelinek <jakub@redhat.com>
>
> PR c++/105186
> * c-common.cc (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.
>
> --- gcc/c-family/c-common.cc.jj 2022-04-07 17:18:14.378883472 +0200
> +++ gcc/c-family/c-common.cc 2022-04-07 17:21:07.950463695 +0200
> @@ -4278,6 +4278,8 @@ 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));
So this also covers the range for the unsigned variants of these types.
I think the patch is OK, thanks.
> sprintf (name, "__int%d unsigned", int_n_data[i].bitsize);
> record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type);
> --- gcc/testsuite/c-c++-common/pr105186.c.jj 2022-04-07 17:25:32.084781386 +0200
> +++ gcc/testsuite/c-c++-common/pr105186.c 2022-04-07 17:25:13.736037189 +0200
> @@ -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" } */
Marek
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-04-09 21:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-08 7:29 [PATCH] c-family: Initialize ridpointers for __int128 etc. [PR105186] Jakub Jelinek
2022-04-09 21:04 ` Marek Polacek
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).