Braced Initialization Error with 32bit GCC for Unsigned Long Long

When I compile the code

 typedef long long unsigned myuint64;
 myuint64 a[2] = {18446744073709551615, 18446744073709551615}; // error on 32bit gcc
 myuint64 b = 18446744073709551615; // no error

on Godbolt with ARM32-GCC I get the errors

(3 warnings for "integer constant is so large that it is unsigned")

error: narrowing conversion of '-1' from 'long long int' to 'myuint64' {aka 'long long unsigned int'} [-Wnarrowing]
    6 |  myuint64 a[2] = {18446744073709551615, 18446744073709551615};
      |                   ^~~~~~~~~~~~~~~~~~~~
error: narrowing conversion of '-1' from 'long long int' to 'myuint64' {aka 'long long unsigned int'} [-Wnarrowing]
    6 |  myuint64 a[2] = {18446744073709551615, 18446744073709551615}; 

(The number is the maximum value for uint64)

I do not get this error when using ARM64-GCC (or 32bit/64bit Clang or 32bit/64bit MSVC).
But I get the error when using other 32bit GCC variants on Godbolt.

Why is this an error with these 32bit GCC compilers only?

I can fix it by using 18446744073709551615u. Is there any other way to fix this error without changing the code and without disabling this warning/error in general (-Wno-narrowing)?

Whether your code compiles or not depends on whether __int128 exists, and it only exists for ARM64 GCC. The reason is that when you write an integer-literal with no suffix such as u, the compiler chooses a type from this list until the value fits in one of these types:

• int
• long int
• long long int
• some implementation-defined extended signed integer type, e.g. __int128

See [lex.icon] §3.

Your value 18446744073709551615 equals 2⁶⁴-1, so a 64-bit signed integer cannot fit it, but __int128 can.

Let's reveal what type ARM64 gcc gives to your integer literal:

// warning: integer constant is so large that it is unsigned
void foo(decltype(18446744073709551615)) {}

foo(__int128):
        ret

The warning message doesn't match what really happens: You can see that the compiler outputs a function accepting __int128, which is the type of your literal.

The same code compiled with ARM gcc (32-bit) produces:

foo(long long):
        bx lr

In this case, the literal is too large to fit any of the types, __int128 doesn't exist (and attempting to use it would produce a compiler error), and GCC chooses to treat this as a warning, not an error.

Why your code only works with 64-bit compilers

myuint64 a[2] = {18446744073709551615, 18446744073709551615};

GCC falsely chooses long long for your literals even though this code is ill-formed, and converts them to -1. myuint64 is unsigned, so it cannot represent -1, and list initialization does not allow narrowing conversion. As a result, we get a compiler error.

With __int128 on a 64-bit compiler, this is not a problem, because we can convert __int128(18446744073709551615) to myuint64(18446744073709551615) just fine.

Conclusion

You have discovered an unusual situation where compiler diagnostics are really counter-intuitive. Ignoring these diagnostics and understanding that __int128 is involved reveals the problem.

I am not aware of any compiler flags that you can use to fix this, so I recommend using the u suffix for literals, in which case the compiler chooses from:

• unsigned int
• unsigned long int
• unsigned long long int
• some implementation-defined extended unsigned integer type, e.g. __uint128