Re: __builtin_add_overflow on clang

[Bruno Haible]

Paul Eggert wrote:
> In many of the builds he could get clang to work by configuring with CC=clang 
> LDFLAGS=--rtlib=compiler-rt. However, this wasn't always enough. Eventually 
> he 
> gave up on using clang to compile GNU sed because of the 
> __builtin_mul_overflow 
> hassle.

Nelson Beebe is not the only one to have problems with clang's compiler-rt.

- Users who build clang from source frequently have issues with the runtime
  not being properly connected to the compiler and/or the OS directories.

- Even when you take the pre-built binaries (I downloaded and installed
  clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz, for example),
  the issue is reproducible:

  $ CC=$HOME/inst-clang/7.0.1/bin/clang
  $ CXX="$HOME/inst-clang/7.0.1/bin/clang++ -L/usr/lib/gcc/x86_64-linux-gnu/5 
-I/usr/include/c++/5 -I/usr/include/x86_64-linux-gnu/c++/5"
  export CC CXX

  $ cat zz9.c
  __int128_t a;
  int main (void) {
    a = a * a;
    return 0;
  }
  $ $CC -fsanitize=undefined zz9.c
  /tmp/zz9-af583f.o: In function `main':
  zz9.c:(.text+0x4c): undefined reference to `__muloti4'
  clang-7: error: linker command failed with exit code 1 (use -v to see 
invocation)

> In many of the builds he could get clang to work by configuring with CC=clang 
> LDFLAGS=--rtlib=compiler-rt.

This does not work for me:

$ $CC --rtlib=compiler-rt -fsanitize=undefined zz9.c
/home/bruno/inst-clang/7.0.1/lib/clang/7.0.1/lib/linux/libclang_rt.ubsan_standalone-x86_64.a(sanitizer_unwind_linux_libcdep.cc.o):
 In function `__sanitizer::Unwind_GetIP(_Unwind_Context*)':
/tmp/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:100:
 undefined reference to `_Unwind_GetIP'
/home/bruno/inst-clang/7.0.1/lib/clang/7.0.1/lib/linux/libclang_rt.ubsan_standalone-x86_64.a(sanitizer_unwind_linux_libcdep.cc.o):
 In function `Unwind_GetIP':
/tmp/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:100:
 undefined reference to `_Unwind_GetIP'
/home/bruno/inst-clang/7.0.1/lib/clang/7.0.1/lib/linux/libclang_rt.ubsan_standalone-x86_64.a(sanitizer_unwind_linux_libcdep.cc.o):
 In function `__sanitizer::BufferedStackTrace::SlowUnwindStack(unsigned long, 
unsigned int)':
/tmp/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:127:
 undefined reference to `_Unwind_Backtrace'
/home/bruno/inst-clang/7.0.1/lib/clang/7.0.1/lib/linux/libclang_rt.ubsan_standalone-x86_64.a(sanitizer_unwind_linux_libcdep.cc.o):
 In function `SlowUnwindStack':
/tmp/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:127:
 undefined reference to `_Unwind_Backtrace'
clang-7: error: linker command failed with exit code 1 (use -v to see 
invocation)

Therefore by assuming that, on a given platform, the compiler-rt of clang
is found, you are treating clang as a vendor compiler. I.e. you are effectively
denying the users of these platforms the freedom to rebuild clang from source.

(The majority of the blame is on the clang project, of course, not on
intprops.h. But the task to integrate a compiler runtime into a working
system is complex. When I build e.g. gcc as a cross-compiler, it's not
easy either to configure it in a way that it finds libgcc and crt1.o.)

Bruno