public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gerald Pfeifer <gerald@pfeifer.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>, gcc-patches@gcc.gnu.org
Subject: Re: [wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html
Date: Fri, 31 Mar 2023 01:07:54 +0200 (CEST)	[thread overview]
Message-ID: <2a7ad485-96b2-34b8-ae28-370ef11a828e@pfeifer.com> (raw)
In-Reply-To: <ZB2LgwL5rK/JI+KH@tucnak>

On Fri, 24 Mar 2023, Jakub Jelinek wrote:
> Shall we mention it in porting_to.html as well?
> The only known affected package is (was?) the Linux kernel.

If in a rebuild of Fedora (or openSUSE) the only affected package is the 
kernel, we probably don't need to go for porting_to.html?

> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> +    <li>The behavior of the GNU C extension support of enumerators which
> +      don't fit into <code>int</code> has been changed to match the C2X
> +      behavior.  Previously, in enumerations where at least one enumerator
> +      didn't fit into <code>int</code>, only those enumerators that didn't
> +      fit into <code>int</code> had the <code>enum</code> type and others
> +      had <code>int</code> type 

So far I understand, and it feels intuitive.

>        and while the <code>enum</code> is being
> +      defined enumerators that didn't fit into <code>int</code> had some
> +      unspecified type with the sign and precision of its value.

This, however, really confuses me.

Should this be "while" (without "and")?

And what are we trying to say here? Can we essentially omit this since
it is a bit more specific, but mostly redundant with the earlier 
statement?

Otherwise, maybe first talk about the elements that fit type int and
then merge the two statements about those that don't?


> +      In GCC13, in such enumerations all enumerators have the
> +      <code>enum</code> type and while the <code>enum</code> is being
> +      defined enumerators that didn't fit into <code>int</code> have
> +      type of their value.

"don't" 

"the type of their value"?

>  If all enumerators fit into <code>int</code>
> +      type, as before all enumerators have <code>int</code> type, both
> +      while the <code>enum</code> is being defined and after it is defined.
> +      See <a href="https://gcc.gnu.org/PR36113">PR36113</a> for details.
> +    </li>

Can we skip this? "In such enumerations" above refers to the special case,
and the simple case (where everything fits into int) has not changed, has 
it?

Gerald

      reply	other threads:[~2023-03-30 23:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24 11:37 Jakub Jelinek
2023-03-30 23:07 ` Gerald Pfeifer [this message]

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=2a7ad485-96b2-34b8-ae28-370ef11a828e@pfeifer.com \
    --to=gerald@pfeifer.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    /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).