From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 03728385770F; Thu, 11 May 2023 18:00:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 03728385770F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683828054; bh=Z2YCbO4KS67vxZwLL2ipPlm2XzctJ7toXCIsgq0DsBY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qCOdj7gN2kGeU4b4amVV+YZ4Jh0yB3x/eZ2So3PGpTzORsPgJ5S73+dHERYifcebp 0W39nPtznG61RLm6xrzmGSyrhqyQR4pPNXstqDpktORVlKEry7TunSQ8BdF02hiWW7 7Mo4jQvAT0Ha7F2ijFQEEAb4C0zCIcHxRmEUjOJA= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Thu, 11 May 2023 18:00:52 +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: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org 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: attachments.created 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=3D102989 --- Comment #35 from Jakub Jelinek --- Created attachment 55055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55055&action=3Dedit gcc14-set-precision.patch Untested preparation patch which prepares fo the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989#c25 idea of keeping 16-bit precision for all types but the new bit-precise inte= ger types and 32-bit precision. Unfortunately it isn't just starting to use SET_TYPE_PRECISION when it is used as an lvalue, but unfortunately the curr= ent TYPE_PRECISION definition which is a unsigned:16 non-static data member for -Wsign-compare acts as either signed or unsigned int and no warning is emit= ted, while even if the new larger precision in some types was unsigned:31, using those two options in a conditional leads to -Wsign-compare warnings because= all of sudden the macro is considered to be either int or unsigned depending on= how exactly it is defined. There are more -Wsign-compare warnings if TYPE_PRECISION is signed int than when it is unsigned int, so I want to implement the latter and this patch also adjusts all spots I've noticed to avoid the -Wsign-compare warnings. Precision is never negative...=