[Bug driver/107954] New: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[Bug driver/107954] New: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[romain.geissler at amadeus dot com]

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

            Bug ID: 107954
           Summary: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I raise this ticket (I agree not very important, and more a feature request
than a bug) following a similar one on C++/clang side and a remark from Aaron
Ballman:
https://github.com/llvm/llvm-project/issues/59300#issuecomment-1335623903

It seems that the future C2x standard has reached at least the feature freeze
phase and the expectations are that it will be ratified in 2023. So, it is
already the time to accept -std=c23/gnu23 as aliases of -std=c2x/gnu2x or is it
early for this ? On C++ side gcc already accepts -std=c++23 since gcc 11 as now
C++ standards seems to strictly follow the 3 years cadence.

Cheers,
Romain

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-12-02
           Keywords|                            |diagnostic,
                   |                            |internal-improvement
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

The following options (and maybe some in the diagnostic messages too) need to
be changed/aliased:
Wc11-c2x-compat
std=c2x

Internally the macros:
D_C2X
STD_C2X
CLK_STDC2X
CLK_GNUC2X

the language name:
c-opts.cc:  lang_hooks.name = "GNU C2X";

And a few other places.
It is early in stage 4 of GCC 13 release cycle but I will leave it up to the C
maintainers to see if they want the change for GCC 13 or wait till stage 1 of
GCC 14.

Confirmed otherwise.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[lukaszcz18 at wp dot pl]

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

Jamaika <lukaszcz18 at wp dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lukaszcz18 at wp dot pl

--- Comment #2 from Jamaika <lukaszcz18 at wp dot pl> ---
I shouldn't be writing as an outsider.
I don't know what c2x accepts.
For gcc 11.3.1 and c++20 I am forced to use c2x.
For example, compiling HTJ2K grok c++20 and zlib shows that zlib does not
conform to c++20 standards and some functions are deprecated.

adler32.c: In function 'adler32_z':
adler32.c:63:15: warning: old-style function definition
[-Wold-style-definition]
   63 | uLong ZEXPORT adler32_z(adler, buf, len)
      |               ^~~~~~~~~
adler32.c: In function 'adler32':
adler32.c:134:15: warning: old-style function definition
[-Wold-style-definition]
  134 | uLong ZEXPORT adler32(adler, buf, len)
      |               ^~~~~~~
adler32.c: In function 'adler32_combine_':
adler32.c:143:13: warning: old-style function definition
[-Wold-style-definition]
  143 | local uLong adler32_combine_(adler1, adler2, len2)
      |             ^~~~~~~~~~~~~~~~
adler32.c: In function 'adler32_combine':
adler32.c:172:15: warning: old-style function definition
[-Wold-style-definition]
  172 | uLong ZEXPORT adler32_combine(adler1, adler2, len2)
      |               ^~~~~~~~~~~~~~~
adler32.c: In function 'adler32_combine64':
adler32.c:180:15: warning: old-style function definition
[-Wold-style-definition]
  180 | uLong ZEXPORT adler32_combine64(adler1, adler2, len2)
      |               ^~~~~~~~~~~~~~~~~
compress.c: In function 'compress2':
compress.c:22:13: warning: old-style function definition
[-Wold-style-definition]
   22 | int ZEXPORT compress2(dest, destLen, source, sourceLen, level)
      |             ^~~~~~~~~
compress.c: In function 'compress':
compress.c:68:13: warning: old-style function definition
[-Wold-style-definition]
   68 | int ZEXPORT compress(dest, destLen, source, sourceLen)
      |             ^~~~~~~~
compress.c: In function 'compressBound':
compress.c:81:15: warning: old-style function definition
[-Wold-style-definition]
   81 | uLong ZEXPORT compressBound(sourceLen)
      |               ^~~~~~~~~~~~~
crc32.c: In function 'byte_swap':
crc32.c:126:16: warning: old-style function definition [-Wold-style-definition]
  126 | local z_word_t byte_swap(word)
      |                ^~~~~~~~~
crc32.c: In function 'multmodp':
crc32.c:551:15: warning: old-style function definition [-Wold-style-definition]
  551 | local z_crc_t multmodp(a, b)
      |               ^~~~~~~~
crc32.c: In function 'x2nmodp':
crc32.c:575:15: warning: old-style function definition [-Wold-style-definition]
  575 | local z_crc_t x2nmodp(n, k)
      |               ^~~~~~~
crc32.c: In function 'crc_word':
crc32.c:726:15: warning: old-style function definition [-Wold-style-definition]
  726 | local z_crc_t crc_word(data)
      |               ^~~~~~~~
crc32.c: In function 'crc_word_big':
crc32.c:735:16: warning: old-style function definition [-Wold-style-definition]
  735 | local z_word_t crc_word_big(data)
      |                ^~~~~~~~~~~~
crc32.c: In function 'crc32_z':
crc32.c:748:23: warning: old-style function definition [-Wold-style-definition]
  748 | unsigned long ZEXPORT crc32_z(crc, buf, len)
      |                       ^~~~~~~
crc32.c: In function 'crc32':
crc32.c:1072:23: warning: old-style function definition
[-Wold-style-definition]
 1072 | unsigned long ZEXPORT crc32(crc, buf, len)
      |                       ^~~~~

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Editorial review before the CD ballot slipped the schedule.  Second-round 
editorial review after a huge number of changes in the editorial review 
slipped the schedule.  Getting a final draft with all the changes into the 
CD ballot process slipped the schedule.  The January meeting is two weeks 
later than originally planned because of the schedule delays.  I just sent 
206 comments on the CD to BSI for submission to ISO as the UK comments and 
if other NBs have similar numbers of comments, (a) it wouldn't surprise me 
if there's difficulty in getting through all of them in a single week's 
meeting (even if we find a way not to need to discuss all the editorial 
comments individually in the meeting) and (b) there could easily be 
further delays getting all the changes into the working draft and reviewed 
for being correctly applied.  So despite the 56-day "ISO editing" period 
on the schedule before the DIS ballot (which may be meant to deal with all 
the editorial issues ISO comes up with at the last minute), it's entirely 
plausible there could be schedule slip for the DIS ballot - even supposing 
we don't need any extra ballot stages (CD2 or FDIS).

So while it's possible that the new standard will be published in 2023 - 
or with a __STDC_VERSION__ value from 2023 even if published in 2024 - 
there is plenty of scope for the schedule to slip given the amount of work 
that still needs to be done on the draft.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[romain.geissler at amadeus dot com]

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

--- Comment #4 from Romain Geissler <romain.geissler at amadeus dot com> ---
In the latest agenda published
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf) it seems that now
the next C revision has been delayed a bit.

At this point, is it known already if it will be officially called C23 or C24 ?

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The straw poll at the June meeting said to keep calling it C23 (votes 
4/12/2 for/against/abstain on the question of changing the informal name 
to C24).  Of course the actual standard will be ISO/IEC 9899:2024 (but 
__STDC_VERSION__ will remain as 202311L, consistent with the informal name 
rather than the publication date, in the absence of a technical DIS 
comment requesting a change of version number being accepted, and 
accepting any technical DIS comments would delay the standard by requiring 
an FDIS).

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[daniel.lundin.mail at gmail dot com]

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

Daniel Lundin <daniel.lundin.mail at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.lundin.mail at gmail dot co
                   |                            |m

--- Comment #6 from Daniel Lundin <daniel.lundin.mail at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #5)
> The straw poll at the June meeting said to keep calling it C23 (votes 
> 4/12/2 for/against/abstain on the question of changing the informal name 
> to C24).  Of course the actual standard will be ISO/IEC 9899:2024 (but 
> __STDC_VERSION__ will remain as 202311L, consistent with the informal name 
> rather than the publication date, in the absence of a technical DIS 
> comment requesting a change of version number being accepted, and 
> accepting any technical DIS comments would delay the standard by requiring 
> an FDIS).

Please keep in mind that -std=c2x uses a placeholder value of 202000L for
__STDC_VERSION__, whereas WG14 has decided that 202311L should be used for the
final version. Worth considering when -std=c23 goes live.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[cvs-commit at gcc dot gnu.org]

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

--- 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:fad61bf73b3158157a136bf4d9373fc3d9afe319

commit r14-5160-gfad61bf73b3158157a136bf4d9373fc3d9afe319
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Nov 6 15:01:22 2023 +0000

    c: Add -std=c23, -std=gnu23, -Wc11-c23-compat options [PR107954]

    At the June WG14 meeting, WG14 decided it preferred to keep C23 as the
    informal name for the next revision of the C standard, despite
    publication not being before 2024 (publication is due in 2024 whether
    or not technical changes at the January meeting result in an FDIS
    ballot being needed).  At the Cauldron I raised the question of
    whether we should thus now add option names such as -std=c23 to GCC,
    and there was support for doing so.

    Add -std=c23, making -std=c2x a deprecated alias; also add the alias
    -std=iso9899:2024.  Likewise, add -std=gnu23, making -std=gnu2x a
    deprecated alias, and add -Wc11-c23-compat, making -Wc11-c2x-compat a
    deprecated alias.

    Here, I'm generally just adding the new options and making the minimum
    changes required to do so, with documentation changed to refer to C23
    instead of C2X only where directly associated with documentation of
    these options.  It's intended that future changes will update
    documentation, diagnostics, comments, variable names, testcase names,
    etc. to refer consistently to C23.  When such changes are made, the
    new tests c23-opts-3.c, c23-opts-5.c and gnu23-opts-2.c are intended
    to keep using the old option names they are specifically testing,
    while other tests would start using the c23/gnu23 versions of the
    names (as well as the tests themselves being renamed).

    Updating option names is independent of updating to the final
    __STDC_VERSION__ value.  There, the question is whether we should
    update the value now or wait for the remaining significant features to
    be implemented first.  (I intend to review Martin's tag compatibility
    patches for GCC 14.  I'm not aware of anyone working on #embed - or on
    the [[unsequenced]] and [[reproducible]] attributes, though support
    for standard attributes is optional.)

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

            PR c/107954

    gcc/
            * doc/cpp.texi (__STDC_VERSION__): Refer to -std=c23 and
            -std=gnu23 instead of -std=c2x and -std=gnu2x.
            * doc/extend.texi (Attribute Syntax): Refer to C23 and -std=c23
            instead of C2x and -std=c2x.
            * doc/invoke.texi (-Wc11-c23-compat, -std=c23, -std=gnu23)
            (-std=iso9899:2024): Document, with -Wc11-c2x-compat, -std=c2x and
            -std=gnu2x as deprecated aliases.  Update descriptions of C23.
            * doc/standards.texi (Standards): Describe C23 with C2X as an old
            name.

    gcc/c-family/
            * c.opt (Wc11-c2x-compat): Rename to Wc11-c23-compat and make into
            a deprecated alias of Wc11-c23-compat.
            (std=c2x): Rename to std=c23 and make into a deprecated alias of
            std=c23.
            (std=gnu2x): Rename to std=gnu23 and make into a deprecated alias
            of std=gnu23.
            (std=iso9899:2024): New option.  Alias of std=c23.
            * c-lex.cc (interpret_float): Use OPT_Wc11_c23_compat instead of
            OPT_Wc11_c2x_compat.
            * c-opts.cc (c_common_handle_option): Use OPT_std_c23 instead of
            OPT_std_c2x and OPT_std_gnu23 instead of OPT_std_gnu2x.

    gcc/c/
            * c-errors.cc (pedwarn_c11): Use OPT_Wc11_c23_compat instead of
            OPT_Wc11_c2x_compat.
            * c-typeck.cc (build_conditional_expr, convert_for_assignment):
            Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat.

    gcc/testsuite/
            * gcc.dg/c23-opts-1.c, gcc.dg/c23-opts-2.c, gcc.dg/c23-opts-3.c,
            gcc.dg/c23-opts-4.c, gcc.dg/c23-opts-5.c, gcc.dg/gnu23-opts-1.c,
            gcc.dg/gnu23-opts-2.c: New tests.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[jsm28 at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
These option names have now been implemented, and all references to the old
names updated in the source tree except for documentation and tests
specifically for the old names, given the preference in WG14 to keep C23 as the
informal name despite the 2024 publication date, and the view at the Cauldron
that it's thus now time to add these options to GCC.