From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id A84963858D35 for ; Thu, 30 Mar 2023 23:07:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A84963858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 16C6033E5C; Thu, 30 Mar 2023 19:07:57 -0400 (EDT) Received: from naga.localdomain (62-47-129-209.adsl.highway.telekom.at [62.47.129.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id 617EE33E56; Thu, 30 Mar 2023 19:07:56 -0400 (EDT) Date: Fri, 31 Mar 2023 01:07:54 +0200 (CEST) From: Gerald Pfeifer To: Jakub Jelinek cc: "Joseph S. Myers" , gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html In-Reply-To: Message-ID: <2a7ad485-96b2-34b8-ae28-370ef11a828e@pfeifer.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.143 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 > +
  • The behavior of the GNU C extension support of enumerators which > + don't fit into int has been changed to match the C2X > + behavior. Previously, in enumerations where at least one enumerator > + didn't fit into int, only those enumerators that didn't > + fit into int had the enum type and others > + had int type So far I understand, and it feels intuitive. > and while the enum is being > + defined enumerators that didn't fit into int 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 > + enum type and while the enum is being > + defined enumerators that didn't fit into int have > + type of their value. "don't" "the type of their value"? > If all enumerators fit into int > + type, as before all enumerators have int type, both > + while the enum is being defined and after it is defined. > + See PR36113 for details. > +
    • 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