public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/61469] New: language feature: Support for enum underlying type
@ 2014-06-11  9:58 nick87720z at gmail dot com
  2014-06-11 10:04 ` [Bug c/61469] " redi at gcc dot gnu.org
                   ` (15 more replies)
  0 siblings, 16 replies; 17+ messages in thread
From: nick87720z at gmail dot com @ 2014-06-11  9:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

            Bug ID: 61469
           Summary: language feature: Support for enum underlying type
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nick87720z at gmail dot com

Just like some other features (inline functions, const, bool), ability to
specify data type for enumeration should be useful, since enumeration is just a
restriction for possible values.

Unlike C++, where type is specified as "enum class type ...", i propose
following forms:
- enum(type) ...
- type enum ...


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
@ 2014-06-11 10:04 ` redi at gcc dot gnu.org
  2014-06-11 10:13 ` nick87720z at gmail dot com
                   ` (14 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2014-06-11 10:04 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to nick87720z from comment #0)
> Unlike C++, where type is specified as "enum class type ..."

That's not how C++ does it, the correct syntax is:

  enum foo_type : int { foo, bar, baz };


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
  2014-06-11 10:04 ` [Bug c/61469] " redi at gcc dot gnu.org
@ 2014-06-11 10:13 ` nick87720z at gmail dot com
  2014-06-11 10:25 ` redi at gcc dot gnu.org
                   ` (13 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: nick87720z at gmail dot com @ 2014-06-11 10:13 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #2 from nick87720z at gmail dot com ---
Didn't know about this form. What i mentioned, i found othere:
http://en.wikipedia.org/wiki/Enumerated_type#C.2B.2B


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
  2014-06-11 10:04 ` [Bug c/61469] " redi at gcc dot gnu.org
  2014-06-11 10:13 ` nick87720z at gmail dot com
@ 2014-06-11 10:25 ` redi at gcc dot gnu.org
  2014-06-11 10:40 ` mpolacek at gcc dot gnu.org
                   ` (12 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2014-06-11 10:25 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You're confusing two separate things, that's a "scoped enumeration" which is
orthogonal to defining a fixed underlying type for an enumeration.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (2 preceding siblings ...)
  2014-06-11 10:25 ` redi at gcc dot gnu.org
@ 2014-06-11 10:40 ` mpolacek at gcc dot gnu.org
  2014-06-11 11:29 ` nick87720z at gmail dot com
                   ` (11 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-06-11 10:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
But those other features (inline functions, const, bool) are specified by
standard.  What is the use case?  If you want to save space, there's
__attribute__ ((__packed__)) or -fshort-enums (use with caution).
We should be very careful with adding such extensions.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (3 preceding siblings ...)
  2014-06-11 10:40 ` mpolacek at gcc dot gnu.org
@ 2014-06-11 11:29 ` nick87720z at gmail dot com
  2021-12-05 10:20 ` pinskia at gcc dot gnu.org
                   ` (10 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: nick87720z at gmail dot com @ 2014-06-11 11:29 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #5 from nick87720z at gmail dot com ---
I remember case, when bigger size, than from int, was needed - it was 64-bit
integer, used as flag container. Program, using it, is not my. When i decided
to reimplement it as enum, author explained me problem.

As for standard, there are still things not in standard - GCC extensions
(such as computed labels, for which i even exactly know possible use case -
some kind of bridges to seemlessly skip certain checks, which are useless after
decision is done all, with one or two exceptions)
and this one, imho, is good candidate for implementation;
personally i don't care very much about other compilers, thus don't fear of
such proposals :].


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (4 preceding siblings ...)
  2014-06-11 11:29 ` nick87720z at gmail dot com
@ 2021-12-05 10:20 ` pinskia at gcc dot gnu.org
  2022-05-17 10:28 ` egallager at gcc dot gnu.org
                   ` (9 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-05 10:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-12-05
             Status|UNCONFIRMED                 |NEW

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #6)
> There is a proposed enhancement for C2X to implement the ability to define
> the type to be used to represent an enum:
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf>.

Updated paper:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2575.pdf

Confirmed, The standard way will be implemented, my bet it will be for GCC 13.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (5 preceding siblings ...)
  2021-12-05 10:20 ` pinskia at gcc dot gnu.org
@ 2022-05-17 10:28 ` egallager at gcc dot gnu.org
  2022-05-17 17:53 ` joseph at codesourcery dot com
                   ` (8 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: egallager at gcc dot gnu.org @ 2022-05-17 10:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to nick87720z from comment #0)
> > Unlike C++, where type is specified as "enum class type ..."
> 
> That's not how C++ does it, the correct syntax is:
> 
>   enum foo_type : int { foo, bar, baz };

clang supports this as an extension in C:

$ clang -Weverything enum.c
warning: include location '/usr/local/include' is unsafe for cross-compilation
[-Wpoison-system-directories]
enum.c:1:6: warning: enumeration types with a fixed underlying type are a Clang
extension [-Wfixed-enum-extension]
enum : int { a }; int main(void) { return 0; }
     ^~~~~
2 warnings generated.

vs. with gcc:

$ /usr/local/bin/gcc enum.c
enum.c:1:6: error: expected '{' before ':' token
    1 | enum : int { a }; int main(void) { return 0; }
      |      ^

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (6 preceding siblings ...)
  2022-05-17 10:28 ` egallager at gcc dot gnu.org
@ 2022-05-17 17:53 ` joseph at codesourcery dot com
  2022-10-27  0:57 ` jsm28 at gcc dot gnu.org
                   ` (7 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: joseph at codesourcery dot com @ 2022-05-17 17:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
N2963 is up for discussion in WG14 tomorrow, but there are still 
significant issues with the wording to resolve.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (7 preceding siblings ...)
  2022-05-17 17:53 ` joseph at codesourcery dot com
@ 2022-10-27  0:57 ` jsm28 at gcc dot gnu.org
  2022-10-28  0:38 ` cvs-commit at gcc dot gnu.org
                   ` (6 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2022-10-27  0:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jsm28 at gcc dot gnu.org

--- Comment #10 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
I'm working on implementing this C2x feature for GCC 13.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (8 preceding siblings ...)
  2022-10-27  0:57 ` jsm28 at gcc dot gnu.org
@ 2022-10-28  0:38 ` cvs-commit at gcc dot gnu.org
  2022-10-28  0:39 ` jsm28 at gcc dot gnu.org
                   ` (5 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-28  0:38 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joseph Myers <jsm28@gcc.gnu.org>:

https://gcc.gnu.org/g:e0997c14af5e8bc4d26e28549cbce99364a1601f

commit r13-3534-ge0997c14af5e8bc4d26e28549cbce99364a1601f
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Fri Oct 28 00:37:28 2022 +0000

    c: C2x enums with fixed underlying type [PR61469]

    C2x adds support for enums with a fixed underlying type specified
    ("enum e : long long;" and similar).  Implement this in the C front
    end.  The same representation is used for these types as in C++, with
    two macros moved from cp-tree.h to c-common.h.

    Such enums can have bool as the underlying type, and various C
    front-end code checking for boolean types is adjusted to use a new
    C_BOOLEAN_TYPE_P to handle such enums the same way as bool.  (Note
    that for C++ we have bug 96496 that enums with underlying type bool
    don't work correctly there.)

    There are various issues with the wording for such enums in the
    current C2x working draft (including but not limited to wording in the
    accepted paper that failed to make it into the working draft), which I
    intend to raise in NB comments.  I think what I've implemented and
    added tests for matches the intent.

    Bootstrapped with no regressions for x86_64-pc-linux-gnu.

            PR c/61469

    gcc/c-family/
            * c-common.h (ENUM_UNDERLYING_TYPE, ENUM_FIXED_UNDERLYING_TYPE_P):
            New.  Moved from cp/cp-tree.h.
            * c-warn.cc (warnings_for_convert_and_check): Do not consider
            conversions to enum with underlying type bool to overflow.

    gcc/c/
            * c-convert.cc (c_convert): Handle enums with underlying boolean
            type like bool.
            * c-decl.cc (shadow_tag_warned): Allow shadowing declarations for
            enums with enum type specifier, but give errors for storage class
            specifiers, qualifiers or alignment specifiers in non-definition
            declarations of such enums.
            (grokdeclarator): Give error for non-definition use of type
            specifier with an enum type specifier.
            (parser_xref_tag): Add argument has_enum_type_specifier.  Pass it
            to lookup_tag and use it to set ENUM_FIXED_UNDERLYING_TYPE_P.
            (xref_tag): Update call to parser_xref_tag.
            (start_enum): Add argument fixed_underlying_type.  Complete enum
            type with a fixed underlying type given in the definition.  Give
            error for defining without a fixed underlying type in the
            definition if one was given in a prior declaration.  Do not mark
            enums with fixed underlying type as packed for -fshort-enums.
            Store the enum type in the_enum.
            (finish_enum): Do not adjust types of values or check their range
            for an enum with a fixed underlying type.  Set underlying type of
            enum and variants.
            (build_enumerator): Check enumeration constants for enum with
            fixed underlying type against that type and convert to that type.
            Increment in the underlying integer type, with handling for bool.
            (c_simulate_enum_decl): Update call to start_enum.
            (declspecs_add_type): Set specs->enum_type_specifier_ref_p.
            * c-objc-common.cc (c_get_alias_set): Use ENUM_UNDERLYING_TYPE
            rather than recomputing an underlying type based on size.
            * c-parser.cc (c_parser_declspecs)
            (c_parser_struct_or_union_specifier, c_parser_typeof_specifier):
            Set has_enum_type_specifier for type specifiers.
            (c_parser_enum_specifier): Handle enum type specifiers.
            (c_parser_struct_or_union_specifier): Update call to
            parser_xref_tag.
            (c_parser_omp_atomic): Check for boolean increment or decrement
            using C_BOOLEAN_TYPE_P.
            * c-tree.h (C_BOOLEAN_TYPE_P): New.
            (struct c_typespec): Add has_enum_type_specifier.
            (struct c_declspecs): Add enum_type_specifier_ref_p.
            (struct c_enum_contents): Add enum_type.
            (start_enum, parser_xref_tag): Update prototypes.
            * c-typeck.cc (composite_type): Allow for enumerated types
            compatible with bool.
            (common_type, comptypes_internal, perform_integral_promotions):
            Use ENUM_UNDERLYING_TYPE.
            (parser_build_binary_op, build_unary_op, convert_for_assignment)
            (c_finish_return, c_start_switch, build_binary_op): Check for
            boolean types using C_BOOLEAN_TYPE_P.

    gcc/cp/
            * cp-tree.h (ENUM_FIXED_UNDERLYING_TYPE_P, ENUM_UNDERLYING_TYPE):
            Remove.  Moved to c-common.h.

    gcc/testsuite/
            * gcc.dg/c11-enum-4.c, gcc.dg/c11-enum-5.c, gcc.dg/c11-enum-6.c,
            gcc.dg/c2x-enum-6.c, gcc.dg/c2x-enum-7.c, gcc.dg/c2x-enum-8.c,
            gcc.dg/gnu2x-enum-1.c: New tests.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (9 preceding siblings ...)
  2022-10-28  0:38 ` cvs-commit at gcc dot gnu.org
@ 2022-10-28  0:39 ` jsm28 at gcc dot gnu.org
  2024-04-30 16:35 ` thomas.mercier.jr at gmail dot com
                   ` (4 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2022-10-28  0:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |13.0

--- Comment #12 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Implemented for GCC 13.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (10 preceding siblings ...)
  2022-10-28  0:39 ` jsm28 at gcc dot gnu.org
@ 2024-04-30 16:35 ` thomas.mercier.jr at gmail dot com
  2024-04-30 16:39 ` pinskia at gcc dot gnu.org
                   ` (3 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: thomas.mercier.jr at gmail dot com @ 2024-04-30 16:35 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Thomas Mercier <thomas.mercier.jr at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas.mercier.jr at gmail dot com

--- Comment #13 from Thomas Mercier <thomas.mercier.jr at gmail dot com> ---
Was this feature meant to be protected by -std=c23? It doesn't appear to be in
GCC 13:

/tmp$ cat test.c
enum node_stat_item : unsigned {
        NR_LRU_BASE = -1,
        NR_INACTIVE_ANON = NR_LRU_BASE, /* must match order of LRU_[IN]ACTIVE
*/
        NR_ACTIVE_ANON,         /*  "     "     "   "       "         */
        NR_INACTIVE_FILE,
};

int main()
{}
/tmp$ gcc --version
gcc (Debian 13.2.0-10) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

/tmp$ gcc -std=c11 test.c
test.c:2:23: error: enumerator value outside the range of underlying type
    2 |         NR_LRU_BASE = -1,
      |                       ^
test.c:4:9: error: overflow in enumeration values
    4 |         NR_ACTIVE_ANON,         /*  "     "     "   "       "        
*/
      |

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (11 preceding siblings ...)
  2024-04-30 16:35 ` thomas.mercier.jr at gmail dot com
@ 2024-04-30 16:39 ` pinskia at gcc dot gnu.org
  2024-04-30 16:48 ` thomas.mercier.jr at gmail dot com
                   ` (2 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-30 16:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thomas Mercier from comment #13)
> Was this feature meant to be protected by -std=c23? It doesn't appear to be
> in GCC 13:
> 
> /tmp$ cat test.c
> enum node_stat_item : unsigned {
> 	NR_LRU_BASE = -1,
> 	NR_INACTIVE_ANON = NR_LRU_BASE, /* must match order of LRU_[IN]ACTIVE */
> 	NR_ACTIVE_ANON,		/*  "     "     "   "       "         */
> 	NR_INACTIVE_FILE,
> };
> 
> int main()
> {}
> /tmp$ gcc --version
> gcc (Debian 13.2.0-10) 13.2.0
> Copyright (C) 2023 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> /tmp$ gcc -std=c11 test.c
> test.c:2:23: error: enumerator value outside the range of underlying type
>     2 |         NR_LRU_BASE = -1,
>       |                       ^
> test.c:4:9: error: overflow in enumeration values
>     4 |         NR_ACTIVE_ANON,         /*  "     "     "   "       "       
> */
>       |

Note that is the correct error even for C23. clang also errors out the similar
way:
```
<source>:5:2: error: enumerator value 4294967296 is not representable in the
underlying type 'unsigned int'
    5 |         NR_ACTIVE_ANON,         /*  "     "     "   "       "        
*/
      |         ^
```

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (12 preceding siblings ...)
  2024-04-30 16:39 ` pinskia at gcc dot gnu.org
@ 2024-04-30 16:48 ` thomas.mercier.jr at gmail dot com
  2024-04-30 16:52 ` pinskia at gcc dot gnu.org
  2024-04-30 16:54 ` thomas.mercier.jr at gmail dot com
  15 siblings, 0 replies; 17+ messages in thread
From: thomas.mercier.jr at gmail dot com @ 2024-04-30 16:48 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #15 from Thomas Mercier <thomas.mercier.jr at gmail dot com> ---
No objection to the error message, but I would have expected a syntax error for
standards earlier than 23 which don't claim to support manually specifying the
underlying type for the enum. Like this with gcc 12:

test.c:1:21: error: expected identifier or ‘(’ before ‘:’ token
    1 | enum node_stat_item : unsigned {

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (13 preceding siblings ...)
  2024-04-30 16:48 ` thomas.mercier.jr at gmail dot com
@ 2024-04-30 16:52 ` pinskia at gcc dot gnu.org
  2024-04-30 16:54 ` thomas.mercier.jr at gmail dot com
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-30 16:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thomas Mercier from comment #15)
> No objection to the error message, but I would have expected a syntax error
> for standards earlier than 23 which don't claim to support manually
> specifying the underlying type for the enum. Like this with gcc 12:
> 
> test.c:1:21: error: expected identifier or ‘(’ before ‘:’ token
>     1 | enum node_stat_item : unsigned {

Yes it is supported as an extension to older languages as the syntax does not
conflict with valid code. If you want an error for the extension you can use
-Werror=c11-c23-compat

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c/61469] language feature: Support for enum underlying type
  2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
                   ` (14 preceding siblings ...)
  2024-04-30 16:52 ` pinskia at gcc dot gnu.org
@ 2024-04-30 16:54 ` thomas.mercier.jr at gmail dot com
  15 siblings, 0 replies; 17+ messages in thread
From: thomas.mercier.jr at gmail dot com @ 2024-04-30 16:54 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #17 from Thomas Mercier <thomas.mercier.jr at gmail dot com> ---
I see, thank you!

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2024-04-30 16:54 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-11  9:58 [Bug c/61469] New: language feature: Support for enum underlying type nick87720z at gmail dot com
2014-06-11 10:04 ` [Bug c/61469] " redi at gcc dot gnu.org
2014-06-11 10:13 ` nick87720z at gmail dot com
2014-06-11 10:25 ` redi at gcc dot gnu.org
2014-06-11 10:40 ` mpolacek at gcc dot gnu.org
2014-06-11 11:29 ` nick87720z at gmail dot com
2021-12-05 10:20 ` pinskia at gcc dot gnu.org
2022-05-17 10:28 ` egallager at gcc dot gnu.org
2022-05-17 17:53 ` joseph at codesourcery dot com
2022-10-27  0:57 ` jsm28 at gcc dot gnu.org
2022-10-28  0:38 ` cvs-commit at gcc dot gnu.org
2022-10-28  0:39 ` jsm28 at gcc dot gnu.org
2024-04-30 16:35 ` thomas.mercier.jr at gmail dot com
2024-04-30 16:39 ` pinskia at gcc dot gnu.org
2024-04-30 16:48 ` thomas.mercier.jr at gmail dot com
2024-04-30 16:52 ` pinskia at gcc dot gnu.org
2024-04-30 16:54 ` thomas.mercier.jr at gmail dot com

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