When building stage2 with clang on sparc64, the build fails with [1]: In file included from /var/lib/buildbot/workers/debian-stadler-sparc64/clang-sparc64-linux-multistage/llvm/compiler-rt/lib/sanitizer_common/sanitizer_stackdepot.cpp:17: In file included from /var/lib/buildbot/workers/debian-stadler-sparc64/clang-sparc64-linux-multistage/llvm/compiler-rt/lib/sanitizer_common/sanitizer_stackdepotbase.h:16: In file included from /usr/include/stdio.h:870: /usr/include/bits/stdio-ldbl.h:26:20: error: cannot apply asm label to function after its first use __LDBL_REDIR_DECL (vfprintf) ~~~~~~~~~~~~~~~~~~~^~~~~~~~~ /usr/include/sys/cdefs.h:467:26: note: expanded from macro '__LDBL_REDIR_DECL' extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. After some research, it turned out to be a bug in glibc which triggers an error in clang [2] but not gcc. According to the discussion in [2], the different behavior of clang compared to gcc is intentional and the pattern in question should actually not exist anymore in glibc. According to the discussion in [1], the bug triggers on sparc* only since there is no long double math (__NO_LONG_DOUBLE_MATH) on this target. > [1] https://bugs.llvm.org/show_bug.cgi?id=48650 > [2] https://bugs.llvm.org/show_bug.cgi?id=22830
To clarify: sparc64 has long double, but sparc does not (although perhaps sparcv8plus might have it as an option given it's there in the hardware).
If I understood correctly the issue is asm alias is declared *after* the function prototype, right? Does the fix from https://bugs.llvm.org/show_bug.cgi?id=48650#c4 fix the issue without any regression? If so I can check if it breaks anything on other architectures and prepare a patch.
It fixes the issue but there is another problem now which indicates that we need to link against libatomic: [9/4273] Linking CXX shared library lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so : && /home/glaubitz/llvm-project/build/./bin/clang++ -fPIC -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Werror=return-type -fdiagnostics-color -Wall -std=c++14 -Wno-unused-parameter -g -Wl,-z,defs -Wl,-z,nodelete -m32 -nodefaultlibs -Wl,-z,text -nostdlib++ -Wl,-rpath-link,/home/glaubitz/llvm-project/build/tools/clang/stage2-bins/./lib -shared -Wl,-soname,libclang_rt.ubsan_minimal-sparc.so -o lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.sparc.dir/ubsan_minimal_handlers.cpp.o -Wl,-rpath,"\$ORIGIN/../lib" -lgcc_s -lc && : /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.sparc.dir/ubsan_minimal_handlers.cpp.o: in function `report_this_error(void*)': /home/glaubitz/llvm-project/compiler-rt/lib/ubsan_minimal/../sanitizer_common/sanitizer_atomic_clang.h:80: undefined reference to `__atomic_compare_exchange_4' clang-13: error: linker command failed with exit code 1 (use -v to see invocation) I think, however, that this issue is unrelated.
(In reply to John Paul Adrian Glaubitz from comment #3) > It fixes the issue but there is another problem now which indicates that we > need to link against libatomic: > > [9/4273] Linking CXX shared library > lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so > FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so > : && /home/glaubitz/llvm-project/build/./bin/clang++ -fPIC -fPIC > -fvisibility-inlines-hidden -Werror=date-time > -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter > -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic > -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default > -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > -Wsuggest-override -Wstring-conversion -Werror=return-type > -fdiagnostics-color -Wall -std=c++14 -Wno-unused-parameter -g -Wl,-z,defs > -Wl,-z,nodelete -m32 -nodefaultlibs -Wl,-z,text -nostdlib++ > -Wl,-rpath-link,/home/glaubitz/llvm-project/build/tools/clang/stage2-bins/./ > lib -shared -Wl,-soname,libclang_rt.ubsan_minimal-sparc.so -o > lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so > projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.sparc.dir/ > ubsan_minimal_handlers.cpp.o -Wl,-rpath,"\$ORIGIN/../lib" -lgcc_s -lc && : > /usr/bin/ld: > projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.sparc.dir/ > ubsan_minimal_handlers.cpp.o: in function `report_this_error(void*)': > /home/glaubitz/llvm-project/compiler-rt/lib/ubsan_minimal/../ > sanitizer_common/sanitizer_atomic_clang.h:80: undefined reference to > `__atomic_compare_exchange_4' > clang-13: error: linker command failed with exit code 1 (use -v to see > invocation) > > I think, however, that this issue is unrelated. About this issue, the missing proper atomic on sparcv8 has causes some issue in glibc and required us to add a similar trick to emulate atomic operations that has its own drawbacks (no async-signal-safe, a lot of contention). On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported, but only if the optional CAS instruction is implemented (for instance, LEON processors, but SuperSPARC processors are not). So maybe one option is to limit build for SPARC ISA v9.
> On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported That's surprising news to me.
(In reply to John Paul Adrian Glaubitz from comment #5) > > On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported > > That's surprising news to me. It is on the NEWS file at 'Deprecated and removed features, and other changes affecting compatibility:'.
(In reply to Adhemerval Zanella from comment #6) > (In reply to John Paul Adrian Glaubitz from comment #5) > > > On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported > > > > That's surprising news to me. > > It is on the NEWS file at 'Deprecated and removed features, and other > changes affecting compatibility:'. Sure, but I'm surprised that there was no prior discussion to that as both GCC and the Linux kernel support SPARC V7, so the removal is rather unfortunate ... But we should not hijack this thread for that. Either way, the suggested change fixes this problem for me.
On Wed, 10 Mar 2021, glaubitz at physik dot fu-berlin.de via Glibc-bugs wrote: > Sure, but I'm surprised that there was no prior discussion to that as both GCC > and the Linux kernel support SPARC V7, so the removal is rather unfortunate ... It was discussed on libc-alpha in November 2019. In practice, the SPARC V7 support had been broken for a long time before then (the original patch submission says glibc 2.23 / commit b02840bacdefde318d2ad2f920e50785b9b25d69). So I think the removal was similar in spirit to the removal of support for the original i386 (de facto unsupported from glibc 2.4 onwards / the introduction of NPTL, but it was some years after that before all the i386 code was removed and i486 files moved into the generic i386 locations), which was also about lack of sufficient atomic operations support.
@Adhemerval: In any case, could you try the suggested change and apply it if it's fine? I would then go ahead and raise the baseline for compiler-rt on 32-bit SPARC.
(In reply to John Paul Adrian Glaubitz from comment #9) > @Adhemerval: In any case, could you try the suggested change and apply it if > it's fine? > > I would then go ahead and raise the baseline for compiler-rt on 32-bit SPARC. Ping. Would be great if we could get this fixed as the suggested fix works for me.
(In reply to John Paul Adrian Glaubitz from comment #10) > (In reply to John Paul Adrian Glaubitz from comment #9) > > @Adhemerval: In any case, could you try the suggested change and apply it if > > it's fine? > > > > I would then go ahead and raise the baseline for compiler-rt on 32-bit SPARC. > > Ping. Would be great if we could get this fixed as the suggested fix works > for me. I didn't have time to prepare a patch, if you could send it to libc-alpha I can check and review it.
(In reply to Adhemerval Zanella from comment #11) > I didn't have time to prepare a patch, if you could send it to libc-alpha I > can check and review it. Done: https://sourceware.org/pipermail/libc-alpha/2021-March/124254.html
Any news on this particular issue? The problem still causes LLVM stage2 failing to build on sparc64 in the LLVM CI.
There seems to be unaddressed feedback on the mailing list: https://sourceware.org/pipermail/libc-alpha/2021-March/124313.html
FWIW, Adhemerval has a branch on his Github account which is supposed to address this issue: > https://github.com/zatrazz/glibc/tree/azanella/redir-refactor I haven't been able to test the changes yet, i.e. it didn't work for me for unrelated reasons.
I think this has been fixed in [1] and this bug can be closed. > [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=d0fa09a7701956036ff36f8ca188e9fff81553d8