5 ms·

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

• nine_k 1y ago
  Does C++ have native support for uint256?
  • Arnavion 1y ago
    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/nxoEda3q5 https://gcc.godbolt.org/z/bYf4bor3f https://gcc.godbolt.org/z/bYf4bor3f
• addaon 1y ago
  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 1y ago
  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 1y ago
    The C++ standard doesn't forbid introducing side channels, so the answer to the question is yes.
    • rollcat 1y ago
      With all the UB, I wonder how did we manage to write any secure or safety-critical code at all.
      • wat10000 1y ago
        In C++? We pretty much did not.
      • konstantinua00 1y ago
        this isn't UB, and any other language can do this optimization as well even the one you cult over