c: use CONST_DECL for enumerators in TYPE_VALUES
Commit Message
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.
gcc/ChangeLog:
* godump.cc (go_output_typedef): Use the DECL_INITIAL of the TREE_VALUE.
---
gcc/c/c-decl.cc | 4 +++-
gcc/godump.cc | 9 +++++----
2 files changed, 8 insertions(+), 5 deletions(-)
base-commit: b7501739f3b14ac7749aace93f636d021fd607f7
Comments
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
@@ -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;
@@ -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);