[foota]

Would it be legal for a C(++?) compiler to implement this optimization?

[addaon]

Yes, it complies with the as-if rule; there's no observable difference in behavior. This would apply as well for supporting 64 bit additions within a loop on 32- or 16-bit architectures, for example.

[rollcat]

An unexpected optimisation can introduce a side channel (most commonly timing). This one would be safe, but "how do you tell a compiler which ones [not] to use" is a whole topic by itself.

[Denvercoder9]

The C++ standard doesn't forbid introducing side channels, so the answer to the question is yes.

[rollcat]

With all the UB, I wonder how did we manage to write any secure or safety-critical code at all.

[konstantinua00]

this isn't UB, and any other language can do this optimization as well

even the one you cult over

[wat10000]

In C++? We pretty much did not.

[nine_k]

Does C++ have native support for uint256?

[Arnavion]

With C, it is _BitInt(256) if the compiler supports it. The upper limit of _BitInt is implementation-defined though, so 256 is not guaranteed to be supported. Eg clang on RV64 only supports upto 128, but does support 256 on x64_64. gcc seems to not support _BitInt on RV64 at all, but does support 256 on x86_64.

With C++ the existence of such "extended integer" types is implementation defined. clang at least supports the same _BitInt construct for C++ too. gcc seems to not support it.

So, for the 256 case on x86_64, both clang and gcc seem to only generate the simple adc ripple version: https://gcc.godbolt.org/z/nxoEda3q5 https://gcc.godbolt.org/z/bYf4bor3f