[PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

[PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

[Marek Polacek]

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(-)

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);
 

base-commit: b7501739f3b14ac7749aace93f636d021fd607f7
-- 
2.36.1

Re: [PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

[Marek Polacek]

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

Re: [PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

[Ian Lance Taylor]

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

Re: [PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

[Marek Polacek]

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