* [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634]
@ 2023-03-13 20:15 Jason Merrill
2023-03-13 20:47 ` Jason Merrill
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Jason Merrill @ 2023-03-13 20:15 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available. I considered
trying to make gdbhooks more robust, but it seemed simpler to define
tree_code_type as a reference to the template. This still ends up with a
definition of the reference in each translation unit, but that's allowed by the
ODR because it always refers to the same entity, and is much smaller than
having the whole table in each TU.
PR plugins/108634
gcc/ChangeLog:
* tree-core.h (tree_code_type, tree_code_length):
Define even without inline variable support.
* tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH):
Only one definition.
---
gcc/tree-core.h | 3 +++
gcc/tree.h | 10 ----------
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index fd2be57b78c..545dfd30114 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -2298,6 +2298,7 @@ struct tree_code_type_tmpl {
template <int N>
constexpr enum tree_code_class tree_code_type_tmpl<N>::tree_code_type[];
+static constexpr auto &tree_code_type = tree_code_type_tmpl<0>::tree_code_type;
#else
constexpr inline enum tree_code_class tree_code_type[] = {
#include "all-tree.def"
@@ -2326,6 +2327,8 @@ struct tree_code_length_tmpl {
template <int N>
constexpr unsigned char tree_code_length_tmpl<N>::tree_code_length[];
+static constexpr auto &tree_code_length
+= tree_code_length_tmpl<0>::tree_code_length;
#else
constexpr inline unsigned char tree_code_length[] = {
#include "all-tree.def"
diff --git a/gcc/tree.h b/gcc/tree.h
index 91375f9652f..92ac0e6a214 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -177,12 +177,7 @@ code_helper::is_builtin_fn () const
#define TREE_CODE_CLASS_STRING(CLASS)\
tree_code_class_strings[(int) (CLASS)]
-#if __cpp_inline_variables < 201606L
-#define TREE_CODE_CLASS(CODE) \
- tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)]
-#else
#define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
-#endif
/* Nonzero if NODE represents an exceptional code. */
@@ -276,12 +271,7 @@ code_helper::is_builtin_fn () const
#define EXPR_P(NODE) IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (TREE_CODE (NODE)))
-#if __cpp_inline_variables < 201606L
-#define TREE_CODE_LENGTH(CODE) \
- tree_code_length_tmpl <0>::tree_code_length[(int) (CODE)]
-#else
#define TREE_CODE_LENGTH(CODE) tree_code_length[(int) (CODE)]
-#endif
/* Helper macros for math builtins. */
base-commit: c227508d06a63f9b8fede3fd88813accb447060e
--
2.31.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634]
2023-03-13 20:15 [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634] Jason Merrill
@ 2023-03-13 20:47 ` Jason Merrill
2023-03-13 21:02 ` Jakub Jelinek
2023-03-14 15:42 ` [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634] Jakub Jelinek
2 siblings, 0 replies; 6+ messages in thread
From: Jason Merrill @ 2023-03-13 20:47 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek
On 3/13/23 16:15, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> -- 8< --
>
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
> tree_code_type as a reference to the template. This still ends up with a
> definition of the reference in each translation unit, but that's allowed by the
> ODR because it always refers to the same entity, and is much smaller than
> having the whole table in each TU.
...or I could build with a newer bootstrap compiler, I suppose.
> PR plugins/108634
>
> gcc/ChangeLog:
>
> * tree-core.h (tree_code_type, tree_code_length):
> Define even without inline variable support.
> * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH):
> Only one definition.
> ---
> gcc/tree-core.h | 3 +++
> gcc/tree.h | 10 ----------
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/tree-core.h b/gcc/tree-core.h
> index fd2be57b78c..545dfd30114 100644
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -2298,6 +2298,7 @@ struct tree_code_type_tmpl {
>
> template <int N>
> constexpr enum tree_code_class tree_code_type_tmpl<N>::tree_code_type[];
> +static constexpr auto &tree_code_type = tree_code_type_tmpl<0>::tree_code_type;
> #else
> constexpr inline enum tree_code_class tree_code_type[] = {
> #include "all-tree.def"
> @@ -2326,6 +2327,8 @@ struct tree_code_length_tmpl {
>
> template <int N>
> constexpr unsigned char tree_code_length_tmpl<N>::tree_code_length[];
> +static constexpr auto &tree_code_length
> += tree_code_length_tmpl<0>::tree_code_length;
> #else
> constexpr inline unsigned char tree_code_length[] = {
> #include "all-tree.def"
> diff --git a/gcc/tree.h b/gcc/tree.h
> index 91375f9652f..92ac0e6a214 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -177,12 +177,7 @@ code_helper::is_builtin_fn () const
> #define TREE_CODE_CLASS_STRING(CLASS)\
> tree_code_class_strings[(int) (CLASS)]
>
> -#if __cpp_inline_variables < 201606L
> -#define TREE_CODE_CLASS(CODE) \
> - tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)]
> -#else
> #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
> -#endif
>
> /* Nonzero if NODE represents an exceptional code. */
>
> @@ -276,12 +271,7 @@ code_helper::is_builtin_fn () const
>
> #define EXPR_P(NODE) IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (TREE_CODE (NODE)))
>
> -#if __cpp_inline_variables < 201606L
> -#define TREE_CODE_LENGTH(CODE) \
> - tree_code_length_tmpl <0>::tree_code_length[(int) (CODE)]
> -#else
> #define TREE_CODE_LENGTH(CODE) tree_code_length[(int) (CODE)]
> -#endif
>
>
> /* Helper macros for math builtins. */
>
> base-commit: c227508d06a63f9b8fede3fd88813accb447060e
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634]
2023-03-13 20:15 [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634] Jason Merrill
2023-03-13 20:47 ` Jason Merrill
@ 2023-03-13 21:02 ` Jakub Jelinek
2023-03-13 21:54 ` Jakub Jelinek
2023-03-14 15:42 ` [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634] Jakub Jelinek
2 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2023-03-13 21:02 UTC (permalink / raw)
To: Jason Merrill, Jonathan Wakely; +Cc: gcc-patches
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
> tree_code_type as a reference to the template. This still ends up with a
> definition of the reference in each translation unit, but that's allowed by the
> ODR because it always refers to the same entity, and is much smaller than
> having the whole table in each TU.
>
> PR plugins/108634
>
> gcc/ChangeLog:
>
> * tree-core.h (tree_code_type, tree_code_length):
> Define even without inline variable support.
> * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH):
> Only one definition.
I think it would be better to change gdbhooks.py to match what the code
does.
We should adjust the
# extern const enum tree_code_class tree_code_type[];
# #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
comment because that isn't true even for new bootstrap compiler.
And, I just wonder if
val_tree_code_type = gdb.parse_and_eval('tree_code_type')
couldn't be replaced with
try:
val_tree_code_type = gdb.parse_and_eval('tree_code_type')
except;
val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
or so.
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634]
2023-03-13 21:02 ` Jakub Jelinek
@ 2023-03-13 21:54 ` Jakub Jelinek
0 siblings, 0 replies; 6+ messages in thread
From: Jakub Jelinek @ 2023-03-13 21:54 UTC (permalink / raw)
To: Jason Merrill, Jonathan Wakely, gcc-patches
On Mon, Mar 13, 2023 at 10:02:41PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> > gdbhooks, which expects tree_code_type to always be available. I considered
> > trying to make gdbhooks more robust, but it seemed simpler to define
> > tree_code_type as a reference to the template. This still ends up with a
> > definition of the reference in each translation unit, but that's allowed by the
> > ODR because it always refers to the same entity, and is much smaller than
> > having the whole table in each TU.
> >
> > PR plugins/108634
> >
> > gcc/ChangeLog:
> >
> > * tree-core.h (tree_code_type, tree_code_length):
> > Define even without inline variable support.
> > * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH):
> > Only one definition.
>
> I think it would be better to change gdbhooks.py to match what the code
> does.
> We should adjust the
> # extern const enum tree_code_class tree_code_type[];
> # #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
> comment because that isn't true even for new bootstrap compiler.
> And, I just wonder if
> val_tree_code_type = gdb.parse_and_eval('tree_code_type')
> couldn't be replaced with
> try:
> val_tree_code_type = gdb.parse_and_eval('tree_code_type')
> except;
> val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
> or so.
Or
val_tree_code_type = gdb.parse_and_eval('tree_code_type')
if val_tree_code_type == 0:
val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
Whatever works.
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634]
2023-03-13 20:15 [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634] Jason Merrill
2023-03-13 20:47 ` Jason Merrill
2023-03-13 21:02 ` Jakub Jelinek
@ 2023-03-14 15:42 ` Jakub Jelinek
2023-03-14 15:54 ` Jason Merrill
2 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2023-03-14 15:42 UTC (permalink / raw)
To: Jason Merrill, Jonathan Wakely; +Cc: gcc-patches
Hi!
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
> tree_code_type as a reference to the template.
As I said earlier, I think it is better to tweak gdbhooks.
The following patch does that, I've tested it now both with gcc 12 and
older gcc as system compiler and the patch fixed the latter while keeping
the former working as before.
Ok for trunk?
2023-03-14 Jakub Jelinek <jakub@redhat.com>
PR plugins/108634
* gdbhooks.py (TreePrinter.to_string): Wrap
gdb.parse_and_eval('tree_code_type') in a try block, parse
and eval 'tree_code_type_tmpl<0>::tree_code_type' instead if it
raises exception. Update comments for the recent tree_code_type
changes.
--- gcc/gdbhooks.py.jj 2023-03-04 11:24:01.348791347 +0100
+++ gcc/gdbhooks.py 2023-03-14 16:35:48.445671242 +0100
@@ -220,13 +220,23 @@ class TreePrinter:
val_TREE_CODE = self.node.TREE_CODE()
- # extern const enum tree_code_class tree_code_type[];
+ # constexpr inline enum tree_code_class tree_code_type[] = { ... };
# #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
+ # or
+ # template <int N>
+ # struct tree_code_type_tmpl {
+ # static constexpr enum tree_code_class tree_code_type[] = { ... };
+ # }; };
+ # #define TREE_CODE_CLASS(CODE) \
+ # tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)]
if val_TREE_CODE == 0xa5a5:
return '<ggc_freed 0x%x>' % intptr(self.gdbval)
- val_tree_code_type = gdb.parse_and_eval('tree_code_type')
+ try:
+ val_tree_code_type = gdb.parse_and_eval('tree_code_type')
+ except:
+ val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
val_tclass = val_tree_code_type[val_TREE_CODE]
val_tree_code_name = gdb.parse_and_eval('tree_code_name')
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634]
2023-03-14 15:42 ` [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634] Jakub Jelinek
@ 2023-03-14 15:54 ` Jason Merrill
0 siblings, 0 replies; 6+ messages in thread
From: Jason Merrill @ 2023-03-14 15:54 UTC (permalink / raw)
To: Jakub Jelinek, Jonathan Wakely; +Cc: gcc-patches, David Malcolm
On 3/14/23 11:42, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
>> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
>> gdbhooks, which expects tree_code_type to always be available. I considered
>> trying to make gdbhooks more robust, but it seemed simpler to define
>> tree_code_type as a reference to the template.
>
> As I said earlier, I think it is better to tweak gdbhooks.
>
> The following patch does that, I've tested it now both with gcc 12 and
> older gcc as system compiler and the patch fixed the latter while keeping
> the former working as before.
>
> Ok for trunk?
LGTM, OK on Friday if no other comments.
> 2023-03-14 Jakub Jelinek <jakub@redhat.com>
>
> PR plugins/108634
> * gdbhooks.py (TreePrinter.to_string): Wrap
> gdb.parse_and_eval('tree_code_type') in a try block, parse
> and eval 'tree_code_type_tmpl<0>::tree_code_type' instead if it
> raises exception. Update comments for the recent tree_code_type
> changes.
>
> --- gcc/gdbhooks.py.jj 2023-03-04 11:24:01.348791347 +0100
> +++ gcc/gdbhooks.py 2023-03-14 16:35:48.445671242 +0100
> @@ -220,13 +220,23 @@ class TreePrinter:
>
> val_TREE_CODE = self.node.TREE_CODE()
>
> - # extern const enum tree_code_class tree_code_type[];
> + # constexpr inline enum tree_code_class tree_code_type[] = { ... };
> # #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
> + # or
> + # template <int N>
> + # struct tree_code_type_tmpl {
> + # static constexpr enum tree_code_class tree_code_type[] = { ... };
> + # }; };
> + # #define TREE_CODE_CLASS(CODE) \
> + # tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)]
>
> if val_TREE_CODE == 0xa5a5:
> return '<ggc_freed 0x%x>' % intptr(self.gdbval)
>
> - val_tree_code_type = gdb.parse_and_eval('tree_code_type')
> + try:
> + val_tree_code_type = gdb.parse_and_eval('tree_code_type')
> + except:
> + val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
> val_tclass = val_tree_code_type[val_TREE_CODE]
>
> val_tree_code_name = gdb.parse_and_eval('tree_code_name')
>
>
> Jakub
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-03-14 15:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-13 20:15 [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634] Jason Merrill
2023-03-13 20:47 ` Jason Merrill
2023-03-13 21:02 ` Jakub Jelinek
2023-03-13 21:54 ` Jakub Jelinek
2023-03-14 15:42 ` [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634] Jakub Jelinek
2023-03-14 15:54 ` Jason Merrill
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).