Message ID | 20220517202233.415333-1-polacek@redhat.com |
---|---|
State | New |
Headers | show |
Series | c: use CONST_DECL for enumerators in TYPE_VALUES | expand |
On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote: > The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in > the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE > has only the numerical value of the CONST_DECL there. This has caused > me some trouble in my PR105497 patch. Using a CONST_DECL is preferable > because a CONST_DECL can track more information (e.g., attributes), and > you can always get the value simply by looking at its DECL_INITIAL. > > This turned out to be a trivial change. One place in godump.cc had to be > adjusted. I'm not changing the CONST_DECL check in c_do_switch_warnings > because I'll be changing it soon in my next patch. I didn't see any other > checks that this patch makes redundant. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > gcc/c/ChangeLog: > > * c-decl.cc (finish_enum): Store the CONST_DECL into TREE_VALUE, not > its value. The C front-end changes are OK.
On Tue, May 17, 2022 at 09:35:14PM +0000, Joseph Myers wrote: > On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote: > > > The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in > > the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE > > has only the numerical value of the CONST_DECL there. This has caused > > me some trouble in my PR105497 patch. Using a CONST_DECL is preferable > > because a CONST_DECL can track more information (e.g., attributes), and > > you can always get the value simply by looking at its DECL_INITIAL. > > > > This turned out to be a trivial change. One place in godump.cc had to be > > adjusted. I'm not changing the CONST_DECL check in c_do_switch_warnings > > because I'll be changing it soon in my next patch. I didn't see any other > > checks that this patch makes redundant. > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > gcc/c/ChangeLog: > > > > * c-decl.cc (finish_enum): Store the CONST_DECL into TREE_VALUE, not > > its value. > > The C front-end changes are OK. Thanks. Ian, are the (more or less obvious) godump.cc changes also OK? Marek
On Tue, May 17, 2022 at 2:46 PM Marek Polacek <polacek@redhat.com> wrote: > > On Tue, May 17, 2022 at 09:35:14PM +0000, Joseph Myers wrote: > > On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote: > > > > > The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in > > > the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE > > > has only the numerical value of the CONST_DECL there. This has caused > > > me some trouble in my PR105497 patch. Using a CONST_DECL is preferable > > > because a CONST_DECL can track more information (e.g., attributes), and > > > you can always get the value simply by looking at its DECL_INITIAL. > > > > > > This turned out to be a trivial change. One place in godump.cc had to be > > > adjusted. I'm not changing the CONST_DECL check in c_do_switch_warnings > > > because I'll be changing it soon in my next patch. I didn't see any other > > > checks that this patch makes redundant. > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > gcc/c/ChangeLog: > > > > > > * c-decl.cc (finish_enum): Store the CONST_DECL into TREE_VALUE, not > > > its value. > > > > The C front-end changes are OK. > > Thanks. Ian, are the (more or less obvious) godump.cc changes also OK? Yes, that change is OK (assuming it works). Thanks. Ian
On Tue, May 17, 2022 at 02:59:00PM -0700, Ian Lance Taylor wrote: > On Tue, May 17, 2022 at 2:46 PM Marek Polacek <polacek@redhat.com> wrote: > > > > On Tue, May 17, 2022 at 09:35:14PM +0000, Joseph Myers wrote: > > > On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote: > > > > > > > The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in > > > > the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE > > > > has only the numerical value of the CONST_DECL there. This has caused > > > > me some trouble in my PR105497 patch. Using a CONST_DECL is preferable > > > > because a CONST_DECL can track more information (e.g., attributes), and > > > > you can always get the value simply by looking at its DECL_INITIAL. > > > > > > > > This turned out to be a trivial change. One place in godump.cc had to be > > > > adjusted. I'm not changing the CONST_DECL check in c_do_switch_warnings > > > > because I'll be changing it soon in my next patch. I didn't see any other > > > > checks that this patch makes redundant. > > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > gcc/c/ChangeLog: > > > > > > > > * c-decl.cc (finish_enum): Store the CONST_DECL into TREE_VALUE, not > > > > its value. > > > > > > The C front-end changes are OK. > > > > Thanks. Ian, are the (more or less obvious) godump.cc changes also OK? > > Yes, that change is OK (assuming it works). Thanks. Thanks. It still works, the code in question is tested by e.g. testsuite/gcc.misc-tests/godump-1.c. Marek
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc index e49879ab286..83655548fc4 100644 --- a/gcc/c/c-decl.cc +++ b/gcc/c/c-decl.cc @@ -9253,7 +9253,9 @@ finish_enum (tree enumtype, tree values, tree attributes) DECL_INITIAL (enu) = ini; TREE_PURPOSE (pair) = DECL_NAME (enu); - TREE_VALUE (pair) = ini; + /* To match the C++ FE, store the CONST_DECL rather than just its + value. */ + TREE_VALUE (pair) = enu; } TYPE_VALUES (enumtype) = values; diff --git a/gcc/godump.cc b/gcc/godump.cc index 2ae0bcc9672..c0f52bbd0f2 100644 --- a/gcc/godump.cc +++ b/gcc/godump.cc @@ -1114,6 +1114,7 @@ go_output_typedef (class godump_container *container, tree decl) struct macro_hash_value *mhval; void **slot; char buf[WIDE_INT_PRINT_BUFFER_SIZE]; + tree value = DECL_INITIAL (TREE_VALUE (element)); name = IDENTIFIER_POINTER (TREE_PURPOSE (element)); @@ -1127,12 +1128,12 @@ go_output_typedef (class godump_container *container, tree decl) if (*slot != NULL) macro_hash_del (*slot); - if (tree_fits_shwi_p (TREE_VALUE (element))) + if (tree_fits_shwi_p (value)) snprintf (buf, sizeof buf, HOST_WIDE_INT_PRINT_DEC, - tree_to_shwi (TREE_VALUE (element))); - else if (tree_fits_uhwi_p (TREE_VALUE (element))) + tree_to_shwi (value)); + else if (tree_fits_uhwi_p (value)) snprintf (buf, sizeof buf, HOST_WIDE_INT_PRINT_UNSIGNED, - tree_to_uhwi (TREE_VALUE (element))); + tree_to_uhwi (value)); else print_hex (wi::to_wide (element), buf);