[wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html

[wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html

[Jakub Jelinek]

Hi!

The following patch attempts to document the PR36113 changes to the
GNU C extension support of enumerators which don't fit into int.

Ok for wwwdocs?

Shall we mention it in porting_to.html as well?
The only known affected package is (was?) the Linux kernel.

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index f8e9560c..d2035435 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -59,6 +59,22 @@ a work-in-progress.</p>
       <a href="https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/ARM-iWMMXt-Built-in-Functions.html">
       iWMMXt built-in functions</a>.
     </li>
+    <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 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.
+      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.  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>
 </ul>
 
 

	Jakub

Re: [wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html

[Gerald Pfeifer]

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