John Paul Adrian Glaubitz
John Paul Adrian Glaubitz
OK, it seems that clang handles the combination of "-m32" and "-mcpu=v9" incorrectly: glaubitz@gcc202:~/llvm-project/build$ clang++ -DHAVE_RPC_XDR_H=1 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/sanitizer_common -I/home/glaubitz/llvm-project/compiler-rt/lib/sanitizer_common -Iinclude -I/home/glaubitz/llvm-project/llvm/include -I/home/glaubitz/llvm-project/compiler-rt/lib/sanitizer_common/.. -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new...
Hmm, there are more issues with the sanitizer on Linux/sparc64. I also had to properly define pc and sp on Linux: diff --git a/compiler-rt/cmake/base-config-ix.cmake b/compiler-rt/cmake/base-config-ix.cmake index 1edab43e7c0d..94ed0b5e1d19 100644 --- a/compiler-rt/cmake/base-config-ix.cmake...
> This is a known issue: cf. Bug 42535. On Solaris/SPARC, only SPARC V9 CPUs > are > supported and I avoid the issue by relying on that: > https://reviews.llvm.org/D86621....
> It seems to me a solution could be to move the #include > up a bit, so instead of: > > /* If we are compiling with optimizing read...
Reported as a bug in glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=27558
Hmm, that sounds more like a bug in glibc then. Although I don't understand the connection between long double math and the __asm label.
The CI results can be found here: https://lab.llvm.org/staging/#/builders/113 The instance was missing the `crypt.h` header which is why I installed the `libcrypt-dev` package. Multistage builds are fine as long as...
> One outstanding issue is the `__asm` issue that started this bug. For now, I've just hacked around this by having `clang` always predefine `__NO_INLINE__` on Linux/sparc. I haven't submitted...
> True, but how long will this take first to get into upstream `glibc` and then into Debian packages? I could actually build a patched glibc package just for the...
GDB generally works fine on sparc64. We're using it extensively on sparc64 to debug C/C++ programs. Any suggestions on how to test GDB properly?