From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id C300B385734F; Fri, 28 Oct 2022 10:51:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C300B385734F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666954283;
	bh=qThlsqFeRwZjlvy74+oRjp+LOT1a7ZoGkq5/SztvOYg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ZyVCexAfIpejaxgg9EmNXz77NIN15DW25KcLtorGWA2Kz7Rc7WMaKik4AGV+UmmNc
	 2WaKBmv4QxCPp2S6qED4kLiZVrPYvO6TmOthDXLWCV0UlGdggr0TSSZ/D3f/dRC2Cf
	 tHXmR2PiTjn8YKM9Ai3wxlqYkrMnsu1Ftz2wF8rc=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt)
Date: Fri, 28 Oct 2022 10:51:22 +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: rguenther at suse dot de
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: <bug-102989-4-4HBAwQ27Tv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102989-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102989-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989

--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 28 Oct 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989
>=20
> --- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #26)
> > Does the C standard limit the number of bits?  Does it allow
> > implementation defined limits?
>=20
> The latter.  limits.h defines BITINT_MAXWIDTH, which must be at least as =
large
> as number of bits in unsigned long long.  AFAIK LLVM plans 8388608 maximu=
m (but
> due to the missing library support uses 128 as maximum right now).
>=20
> > Constants are tricky indeed but I suppose there's no way to write a
> > 199 bit integer constant in source?  We can always resort to constants
> > of the intfast_t[n] representation (aka a CTOR).
>=20
> One can specify even very large constants in the source.
> 1234567891234567891234567891234567891234567891234567891234567891234567891=
234567891234567891234567891234567891234567891234567891234567891234567891234=
56789123456789123456789123456789123456789123456789123456789uwb
> will be _BitInt with the minimum number of bits to store the above unsign=
ed
> constant.
>=20
> > That said, if C allows us to limit to 128bits then let's do that for no=
w.
> > 32bit targets will still see all the complication when we give that a s=
tab.
>=20
> I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI=
, so
> we can't increase it afterwards.

Quite likely yes (OTOH __BIGGEST_ALIGNMENT__ changed as well).  That
also means BITINT_MAXWIDTH should eventually be decided by the ABI
groups?

I also can hardly see any use for very big N other than "oh, cool".  I=20
mean, we don't have _Float(N) either for N =3D=3D 65000 even though what
would be cool as well.

> Anyway, I'm afraid we probably don't have enough time to implement this
> properly in stage1, so might need to target GCC 14 with it.  Unless someb=
ody
> spends on it
> the remaining 2 weeks full time.

It's absolutely a GCC 14 task given the ABI and library issue.=