[Bug c/102989] Implement C2x's n2763 (_BitInt)

[rguenther at suse dot de]

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

--- 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=102989
> 
> --- 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?
> 
> 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 maximum (but
> due to the missing library support uses 128 as maximum right now).
> 
> > 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).
> 
> One can specify even very large constants in the source.
> 123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789uwb
> will be _BitInt with the minimum number of bits to store the above unsigned
> constant.
> 
> > That said, if C allows us to limit to 128bits then let's do that for now.
> > 32bit targets will still see all the complication when we give that a stab.
> 
> 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 
mean, we don't have _Float(N) either for N == 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 somebody
> spends on it
> the remaining 2 weeks full time.

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