From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 753C5385624A; Fri, 28 Oct 2022 11:02:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 753C5385624A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666954945; bh=18wEx5kO+GFLmScMnCrY7KBronwMOw4LWvG5D0Jd79U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rLnTl/0Di8zapi6Fu3f/jXyHl8I6hXh3meJQzWd6vPDbj6JiUpCezhBYTv6I/U4Q4 Xtby0lubsYdYEaSpXsubwKZU6kN+hGQpRXEPS03Cyvj/3h0XqF0DtnmwEf8zAIU3tn PLDT1fnTARH58kG72fIF2OaY9vwCeee+QPYF12MA= From: "colomar.6.4.3 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Fri, 28 Oct 2022 11:02:24 +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: colomar.6.4.3 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=3D102989 --- Comment #29 from Alejandro Colomar --- Hi! On 10/28/22 12:51, rguenther at suse dot de wrote: > Quite likely yes (OTOH __BIGGEST_ALIGNMENT__ changed as well). That > also means BITINT_MAXWIDTH should eventually be decided by the ABI > groups? >=20 > I also can hardly see any use for very big N other than "oh, cool". I > mean, we don't have _Float(N) either for N =3D=3D 65000 even though what > would be cool as well. I do have a use. Okay, I don't need 8M bits, but 1k is something that woul= d=20 help me. Basically, it's a transparent bignum library, for which I can use most=20 standard C features. BTW, it would also be nice if stdc_count_ones(3) woul= d be=20 implemented to support very wide _BitInt()s as an extension (C23 only guarantees=20 support for _BitInt()s that match a standard or extended type). I have some program that works with matrices of 512x512, represented as arr= ays=20 of 512 members of uint64_t[8], and it popcounts rows, which now means loopi= ng=20 over an array of uint64_t[8] and using the builtin popcount. And I'm not s= ure=20 if I could still optimize it a little bit more. If I could just call the=20 type-generic stdc_count_ones(), and know that the implementation has writte= n a=20 quite optimal loop, that would be great (both for simplicity and performanc= e). Cheers, Alex >=20 >> 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 some= body >> spends on it >> the remaining 2 weeks full time. >=20 > It's absolutely a GCC 14 task given the ABI and library issue. >=