2

I was testing this function and found the behavior is strange method:

uint8_t func(uint32_t x) {
  return std::min<uint8_t>(32, ::__builtin_clz(x)) + 1;
}

call this method func(0) returns 32 on my mac laptop which is supposed to be 33, however if I hard code x as 0 inside the function, it returns expected 33.

g++ version prints on this machine

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

This test behaviors correctly in my test on a linux machine where "g++ -v" prints as

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-11ubuntu0~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-11ubuntu0~18.04.1)

Does anybody have a thought or theory on this issue? Thanks!

Shawn Cao
  • 117
  • 7
  • Wjat is `x` when you call that function? It would surprise me if you really found a compiler bug with _clang_, the more likely reason is that you did something wrong when calling that function, or have a misconception what `::__builtin_clz(x)` is meant to do exactly. – πάντα ῥεῖ Oct 07 '20 at 21:39
  • 7
    Returns the number of leading 0-bits in x, starting at the most significant bit position. **If x is 0, the result is undefined.** – 273K Oct 07 '20 at 21:40
  • @πάνταῥεῖ nothing special in the function call, what I did is just checking func(0) return value. – Shawn Cao Oct 07 '20 at 21:46
  • @S.M. I thought this is most likely the reason, but the result is consistent in many continuous runs, so I doubt if it's caused by some buggy optimization. – Shawn Cao Oct 07 '20 at 21:48
  • I think this is the answer "If x is 0, the result is undefined.", if I tested it in different call sites, I observed different values returned. Thank you all for the quick answers, appreciate it. – Shawn Cao Oct 07 '20 at 21:51

0 Answers0