https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #29 from Alejandro Colomar <colomar.6.4.3 at gmail dot com> --- 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? > > 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 == 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 would help me. Basically, it's a transparent bignum library, for which I can use most standard C features. BTW, it would also be nice if stdc_count_ones(3) would be implemented to support very wide _BitInt()s as an extension (C23 only guarantees support for _BitInt()s that match a standard or extended type). I have some program that works with matrices of 512x512, represented as arrays of 512 members of uint64_t[8], and it popcounts rows, which now means looping over an array of uint64_t[8] and using the builtin popcount. And I'm not sure if I could still optimize it a little bit more. If I could just call the type-generic stdc_count_ones(), and know that the implementation has written a quite optimal loop, that would be great (both for simplicity and performance). Cheers, Alex > >> 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 somebody >> spends on it >> the remaining 2 weeks full time. > > It's absolutely a GCC 14 task given the ABI and library issue. >
