public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/36113] fix C enumerators
Date: Tue, 18 Oct 2022 14:08:21 +0000	[thread overview]
Message-ID: <bug-36113-4-lHEn8xYue0@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-36113-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 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:3b3083a598ca3f4b6203284e01ed39ab6ff0844f

commit r13-3360-g3b3083a598ca3f4b6203284e01ed39ab6ff0844f
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Oct 18 14:07:27 2022 +0000

    c: C2x enums wider than int [PR36113]

    C2x has two enhancements to enumerations: allowing enumerations whose
    values do not all fit in int (similar to an existing extension), and
    allowing an underlying type to be specified (as in C++).  This patch
    implements the first of those enhancements.

    Apart from adjusting diagnostics to reflect this being a standard
    feature, there are some semantics differences from the previous
    extension:

    * The standard feature gives all the values of such an enum the
      enumerated type (while keeping type int if that can represent all
      values of the enumeration), where previously GCC only gave those
      values outside the range of int the enumerated type.  This change
      was previously requested in PR 36113; it seems unlikely that people
      are depending on the detail of the previous extension that some
      enumerators had different types to others depending on whether their
      values could be represented as int, and this patch makes the change
      to types of enumerators unconditionally (if that causes problems in
      practice we could always make it conditional on C2x mode instead).

    * The types *while the enumeration is being defined*, for enumerators
      that can't be represented as int, are now based more directly on the
      types of the expressions used, rather than a possibly different type
      with the right precision constructed using c_common_type_for_size.
      Again, this change is made unconditionally.

    * Where overflow (or wraparound to 0, in the case of an unsigned type)
      when 1 is implicitly added to determine the value of the next
      enumerator was previously an error, it now results in a wider type
      with the same signedness (as the while-being-defined type of the
      previous enumerator) being chosen, if available.

    When a type is chosen in such an overflow case, or when a type is
    chosen for the underlying integer type of the enumeration, it's
    possible that (unsigned) __int128 is chosen.  Although C2x allows for
    such types wider than intmax_t to be considered extended integer
    types, we don't have various features required to do so (integer
    constant suffixes; sufficient library support would also be needed to
    define the associated macros for printf/scanf conversions, and
    <stdint.h> typedef names would need to be defined).  Thus, there are
    also pedwarns for exceeding the range of intmax_t / uintmax_t, as
    while in principle exceeding that range is OK, it's only OK in a
    context where the relevant types meet the requirements for extended
    integer types, which does not currently apply here.

    Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Also
    manually checked diagnostics for c2x-enum-3.c with -m32 to confirm the
    diagnostics in that { target { ! int128 } } test are as expected.

            PR c/36113

    gcc/c-family/
            * c-common.cc (c_common_type_for_size): Add fallback to
            widest_unsigned_literal_type_node or
            widest_integer_literal_type_node for precision that may not
            exactly match the precision of those types.

    gcc/c/
            * c-decl.cc (finish_enum): If any enumerators do not fit in int,
            convert all to the type of the enumeration.  pedwarn if no integer
            type fits all enumerators and default to
            widest_integer_literal_type_node in that case.  Otherwise pedwarn
            for type wider than intmax_t.
            (build_enumerator): pedwarn for enumerators outside the range of
            uintmax_t or intmax_t, and otherwise use pedwarn_c11 for
            enumerators outside the range of int.  On overflow, attempt to
            find a wider type that can hold the value of the next enumerator.
            Do not convert value to type determined with
            c_common_type_for_size.

    gcc/testsuite/
            * gcc.dg/c11-enum-1.c, gcc.dg/c11-enum-2.c, gcc.dg/c11-enum-3.c,
            gcc.dg/c2x-enum-1.c, gcc.dg/c2x-enum-2.c, gcc.dg/c2x-enum-3.c,
            gcc.dg/c2x-enum-4.c, gcc.dg/c2x-enum-5.c: New tests.
            * gcc.dg/pr30260.c: Explicitly use -std=gnu11.  Update expected
            diagnostics.
            * gcc.dg/torture/pr25183.c: Update expected diagnostics.

  parent reply	other threads:[~2022-10-18 14:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-36113-4@http.gcc.gnu.org/bugzilla/>
2021-09-17  7:02 ` pinskia at gcc dot gnu.org
2022-10-18 14:08 ` cvs-commit at gcc dot gnu.org [this message]
2022-10-18 14:13 ` jsm28 at gcc dot gnu.org
2008-05-02 20:14 [Bug c/36113] New: " mrs at apple dot com
2008-05-02 20:17 ` [Bug c/36113] " mrs at apple dot com
2008-05-02 20:17 ` mrs at apple dot com
2008-05-05  6:19 ` pinskia at gcc dot gnu dot org
2008-11-15  0:06 ` pinskia at gcc dot gnu dot org
2008-11-15  0:13 ` pinskia at gcc dot gnu dot org
2008-11-18 20:27 ` mrs at apple dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-36113-4-lHEn8xYue0@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).