From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6E60C3853809; Wed, 26 Oct 2022 07:53:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E60C3853809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666770799; bh=/CoOVfxsGz6CI9P7fvtBvqkK6Bgq6xk0OssRB8rwHTc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BwvyBlysYhpB9u3x0cC7iaEYot3YfbasNu2ckq7bwfMvmdcQGAIoj6tm61D6qaOvj /xiNtRL8In9+wpIkqLdwC1lA3mILeBjLHg6sdsNSdy7IWqXyga3e8R2PcSInXWa7Q5 Tdc27N5BuFZfUDFX18Mn0XIsFaS8DrEZzLloS7uM= From: "jirislaby at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99) Date: Wed, 26 Oct 2022 07:53:15 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jirislaby at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107405 --- Comment #7 from Jiri Slaby --- (In reply to Jakub Jelinek from comment #6) > That is how C++ behaves for years and C2X mandates such behavior too. > Enumerators that don't fit into int were a GNU extensions (-pedantic-erro= rs > rejects them) and for C have been handled weirdly in the past (only speci= fic > enumerators that don't fit had wider types + the enum as whole). > enum E { A =3D 0xdeadbeefcafebabeULL, B =3D 2 }; > int a =3D sizeof (enum E); > int b =3D sizeof (A); > int c =3D sizeof (B); > above yielded a =3D 8, b =3D 8, c =3D 4 in C, a =3D b =3D c =3D 8 in C++ = and now in GCC > 13 in C too. No problem having this in C2X. I'm not complaining about this feature. But well, why does it happen in kernel's gnu11 (and in the example above too)? I mean, I likely can fix the ata enum to be 1U << 31 (using BIT()) and alike = so that it all stays within uint. But how'd you propose to fix this: (In reply to Martin Li=C5=A1ka from comment #2) > Note there's a similar issue I sent patch for: > https://lore.kernel.org/all/f70c7a11-e81e-f6b9-a403-315117f4aa3a@suse.cz/ ? I.e. how to %-format "B" in your example for both gcc-12 (c =3D=3D 4) and= gcc-13 (c =3D=3D 8).=