From: already5chosen@yahoo.com   
      
   On Sat, 29 Nov 2025 17:32:12 -0800   
   Keith Thompson  wrote:   
      
   > Philipp Klaus Krause  writes:   
   > > Am 23.11.25 um 16:06 schrieb Michael S:   
   > >> Upper limit is implementation-defined.   
   > >> On both existing implementations the limit (on 64-bit targets)   
   > >> appears to be 2**16 or  2**16-1. I don't remember which one.   
   >   
   > Recent versions of gcc have BITINT_MAXWIDTH == 65535.   
   >   
   > llvm/clang has BITINT_MAXWIDTH == 8388608 (2**23) (and some serious   
   > performance problems with multiplication and division for large   
   > _BitInt types).   
   >   
      
   According to my measurements, it also have serious performance problems   
   with division that I'd call 'big' rather than large. Like 256 bits.   
      
   Also, it has performance problems with addition and subtraction of   
   large _BitInt types, like in example of Anton Ertl (A+B+C, for   
   N=2**16-64) that we discussed not long ago on comp.arch. However, in   
   this particular case, gcc is only slightly better in speed (but a lot   
   better in code size).   
      
      
   > > Thisis comp.lang.c, not comp.lang.c++. There still are   
   > > implementations of C other than GCC and clang. E.g. SDCC has a   
   > > limit of 64.   
   >   
   > I didn't see any references to C++ in the parent article.  But it's   
   > interesting that SDCC support _BitInt.   
   >   
      
   I'd guess that Philipp Klaus Krause meant to say that there are many   
   more independently developed C compilers than there are C++ compilers,   
   especially so if we only count those that try to be up to date with   
   the most recent language standards.   
   He is, of course, right and I was, of course, wrong in my assumption   
   that no other compilers except gcc and clang implemented _BitInt at the   
   moment.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)