4 ms·
I am pretty sure the code is entirely correct when meant for GCC or Clang. Standards-noncompliance (because of inline assembly) is another issue, of course; but
by nsajko 7y ago
I am pretty sure the code is entirely correct when meant for GCC or Clang. Standards-noncompliance (because of inline assembly) is another issue, of course; but one could argue that GCC and Clang are the de facto standard.
- jdsully 7y agoThe problem would be someone working on the GCC optimizer deciding, “Wouldn’t it be great if we could do all our fancy optimizations on functions with inline assembly?”
- nsajko 7y agoSearch for "volatile" in http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Extended-Asm.html http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Extended-Asm.htm...
- deleted 7y ago[deleted]
- jdsully 7y agoVolatile only says that the clobbered memory is not listed. Nothing would stop the compiler from statically analyzing the assembly to make smarter decisions if it chose to do so. This would be trivial with an empty asm block. However because inline assembly is non-standard even that is not truly guaranteed. Your relying on the good graces of the optimizers that have broken all the other code paths with their legalistic approach.
- nsajko 7y ago> statically analyzing the assembly I must concede this notion troubles me now that you mentioned it, it is indeed possible that GCC or Clang could decide that there is some other way explicit memset-like stuff should be done; and boringssl could deal with it, they are not a stable API for one thing, and Google employs GCC, LLVM and Clang developers anyway so it would be easier for BoringSSL than the rest of the world to fix the compilers changing stuff...
- pjmlp 7y agoOnly on UNIX clones, and even then there are no guarantees of backward compatibility between compiler revisions regarding implementation specific, unspecified and undefined behaviours.