Hans Wennborg via llvm-dev
2018-Aug-06 16:23 UTC
[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> 7.0.0-rc1 was just tagged (from the branch at r338847). >> >> It's early in the release process, but I'd like to find out what the >> status is of the branch on our various platforms. >> >> Please run the test script, share the results, and upload binaries. > > Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our lack of atomic 64 bit primitives; Phase2's configure dies with: > > -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB > -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success > -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB > -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed > -- Looking for __atomic_load_8 in atomic > -- Looking for __atomic_load_8 in atomic - not found > CMake Error at cmake/modules/CheckAtomic.cmake:75 (message): > Host compiler appears to require libatomic, but cannot find it. > > Interestingly, Phase1 does *not* suffer from this, but there the "host compiler" is clang 6.0.0. > > Phase1 CMake output: > > Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB succeeded with the following output: > Change Dir: /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp > > Run Build Command:"/usr/local/bin/gmake" "cmTC_845df/fast" > /usr/local/bin/gmake -f CMakeFiles/cmTC_845df.dir/build.make CMakeFiles/cmTC_845df.dir/build > gmake[1]: Entering directory '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp' > Building CXX object CMakeFiles/cmTC_845df.dir/src.cxx.o > /usr/bin/c++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new -o CMakeFiles/cmTC_845df.dir/src.cxx.o -c /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx > Linking CXX executable cmTC_845df > /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_845df.dir/link.txt --verbose=1 > /usr/bin/c++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new CMakeFiles/cmTC_845df.dir/src.cxx.o -o cmTC_845df -lm > gmake[1]: Leaving directory '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp' > > Source file was: > > #include <atomic> > #include <cstdint> > std::atomic<uint64_t> x (0); > int main() { > uint64_t i = x.load(std::memory_order_relaxed); > return 0; > } > > Phase2 CMake output: > > Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB failed with the following output: > Change Dir: /home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp > > Run Build Command:"/usr/local/bin/gmake" "cmTC_720f3/fast" > /usr/local/bin/gmake -f CMakeFiles/cmTC_720f3.dir/build.make CMakeFiles/cmTC_720f3.dir/build > gmake[1]: Entering directory '/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp' > Building CXX object CMakeFiles/cmTC_720f3.dir/src.cxx.o > /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new -o CMakeFiles/cmTC_720f3.dir/src.cxx.o -c /home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx > Linking CXX executable cmTC_720f3 > /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_720f3.dir/link.txt --verbose=1 > /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new CMakeFiles/cmTC_720f3.dir/src.cxx.o -o cmTC_720f3 -lm > CMakeFiles/cmTC_720f3.dir/src.cxx.o: In function `main': > src.cxx:(.text+0x33): undefined reference to `__atomic_load_8' > clang-7: error: linker command failed with exit code 1 (use -v to see invocation) > gmake[1]: *** [CMakeFiles/cmTC_720f3.dir/build.make:98: cmTC_720f3] Error 1 > gmake[1]: Leaving directory '/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp' > gmake: *** [Makefile:126: cmTC_720f3/fast] Error 2 > > Source file was: > > #include <atomic> > #include <cstdint> > std::atomic<uint64_t> x (0); > int main() { > uint64_t i = x.load(std::memory_order_relaxed); > return 0; > } > > Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have changed. > > For now, I can only test on amd64 due to this, since I don't have an easy workaround.This doesn't sound so good, but I'm glad we found out early. Did you file a bug to track this? (Sorry if you already did, I haven't read through the list today.) Thanks, Hans
Dimitry Andric via llvm-dev
2018-Aug-07 19:49 UTC
[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On 6 Aug 2018, at 18:23, Hans Wennborg <hans at chromium.org> wrote:> > On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric <dimitry at andric.com> wrote: >> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >>> >>> 7.0.0-rc1 was just tagged (from the branch at r338847)....> >> Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our lack of atomic 64 bit primitives; Phase2's configure dies with: >> >> -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB >> -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success >> -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB >> -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed >> -- Looking for __atomic_load_8 in atomic >> -- Looking for __atomic_load_8 in atomic - not found...>> Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have changed....> Did you file a bug to track this? (Sorry if you already did, I haven't > read through the list today.)This is a regression caused by https://reviews.llvm.org/rL323281: ------------------------------------------------------------------------ r323281 | wmi | 2018-01-23 23:27:57 +0000 (Tue, 23 Jan 2018) | 12 lines Adjust MaxAtomicInlineWidth for i386/i486 targets. This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. So in this patch MaxAtomicInlineWidth is reset as follows: For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. Differential Revision: https://reviews.llvm.org/D42154 ------------------------------------------------------------------------ I'm not sure whether we should report this as an LLVM bug though, since the problem really lies with FreeBSD: we never had proper atomic libcalls in our libc (at least the 64 bit ones for 32-bit x86), nor a separate libatomic. Before r323281, and with all released versions of clang to date, it actually generated incorrect instructions for the default target CPU, if you used the triple i386-unknown-freebsd, e.g.: $ ~/obj/clang-323280/bin/clang -m32 -O2 -S atomic-test.cpp -o - [...] pushl %ebp movl %esp, %ebp pushl %ebx xorl %eax, %eax xorl %edx, %edx xorl %ecx, %ecx xorl %ebx, %ebx lock cmpxchg8b x xorl %eax, %eax popl %ebx popl %ebp retl After r323281, this is corrected: $ ~/obj/clang-323281/bin/clang -m32 -O2 -S atomic-test.cpp -o - [...] pushl %ebp movl %esp, %ebp pushl $0 pushl $x calll __atomic_load_8 addl $8, %esp xorl %eax, %eax popl %ebp retl Targeting i586 or higher makes the cmpxchg8b come back: $ ~/obj/clang-323281/bin/clang -m32 -march=i586 -O2 -S atomic-test.cpp -o - [...] pushl %ebp movl %esp, %ebp pushl %ebx xorl %eax, %eax xorl %edx, %edx xorl %ecx, %ecx xorl %ebx, %ebx lock cmpxchg8b x xorl %eax, %eax popl %ebx popl %ebp retl I think there are other scenarios where you could cause atomic libcalls to appear, though, even if you target higher CPUs. That said, we'll have to at least discuss this in the FreeBSD community, since I think it is high time it is fixed on *that* side. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180807/98430a99/attachment.sig>
Hans Wennborg via llvm-dev
2018-Aug-08 12:11 UTC
[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Tue, Aug 7, 2018 at 9:49 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 6 Aug 2018, at 18:23, Hans Wennborg <hans at chromium.org> wrote: >> >> On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric <dimitry at andric.com> wrote: >>> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >>>> >>>> 7.0.0-rc1 was just tagged (from the branch at r338847). > ... >> >>> Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our lack of atomic 64 bit primitives; Phase2's configure dies with: >>> >>> -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB >>> -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success >>> -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB >>> -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed >>> -- Looking for __atomic_load_8 in atomic >>> -- Looking for __atomic_load_8 in atomic - not found > ... >>> Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have changed. > ... >> Did you file a bug to track this? (Sorry if you already did, I haven't >> read through the list today.) > > This is a regression caused by https://reviews.llvm.org/rL323281: > > ------------------------------------------------------------------------ > r323281 | wmi | 2018-01-23 23:27:57 +0000 (Tue, 23 Jan 2018) | 12 lines > > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > Differential Revision: https://reviews.llvm.org/D42154 > ------------------------------------------------------------------------ > > I'm not sure whether we should report this as an LLVM bug though, since > the problem really lies with FreeBSD: we never had proper atomic > libcalls in our libc (at least the 64 bit ones for 32-bit x86), nor a > separate libatomic. > > Before r323281, and with all released versions of clang to date, it > actually generated incorrect instructions for the default target CPU, > if you used the triple i386-unknown-freebsd, e.g.: > > $ ~/obj/clang-323280/bin/clang -m32 -O2 -S atomic-test.cpp -o - > [...] > pushl %ebp > movl %esp, %ebp > pushl %ebx > xorl %eax, %eax > xorl %edx, %edx > xorl %ecx, %ecx > xorl %ebx, %ebx > lock cmpxchg8b x > xorl %eax, %eax > popl %ebx > popl %ebp > retl > > After r323281, this is corrected: > > $ ~/obj/clang-323281/bin/clang -m32 -O2 -S atomic-test.cpp -o - > [...] > pushl %ebp > movl %esp, %ebp > pushl $0 > pushl $x > calll __atomic_load_8 > addl $8, %esp > xorl %eax, %eax > popl %ebp > retl > > Targeting i586 or higher makes the cmpxchg8b come back: > > $ ~/obj/clang-323281/bin/clang -m32 -march=i586 -O2 -S atomic-test.cpp -o - > [...] > pushl %ebp > movl %esp, %ebp > pushl %ebx > xorl %eax, %eax > xorl %edx, %edx > xorl %ecx, %ecx > xorl %ebx, %ebx > lock cmpxchg8b x > xorl %eax, %eax > popl %ebx > popl %ebp > retl > > I think there are other scenarios where you could cause atomic libcalls > to appear, though, even if you target higher CPUs. > > That said, we'll have to at least discuss this in the FreeBSD community, > since I think it is high time it is fixed on *that* side.Thanks for the explanation. Let me know what comes out of the discussion. Cheers, Hans
Joerg Sonnenberger via llvm-dev
2018-Aug-15 22:51 UTC
[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:> This is a regression caused by https://reviews.llvm.org/rL323281: > > ------------------------------------------------------------------------ > r323281 | wmi | 2018-01-23 23:27:57 +0000 (Tue, 23 Jan 2018) | 12 lines > > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.This seems to be somewhat undesirable. Does *anyone* care about real i386 support at this point? NetBSD certainly doesn't and I think we are already the odd man for a number of cases like this. Joerg
Dimitry Andric via llvm-dev
2018-Aug-17 20:27 UTC
[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: >> This is a regression caused by https://reviews.llvm.org/rL323281: >> >> ------------------------------------------------------------------------ >> r323281 | wmi | 2018-01-23 23:27:57 +0000 (Tue, 23 Jan 2018) | 12 lines >> >> Adjust MaxAtomicInlineWidth for i386/i486 targets. >> >> This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. >> Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, >> i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. >> So in this patch MaxAtomicInlineWidth is reset as follows: >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. >> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > This seems to be somewhat undesirable. Does *anyone* care about real > i386 support at this point? NetBSD certainly doesn't and I think we are > already the odd man for a number of cases like this.Yes, and since this causes quite a number of regressions for us, I would really prefer this revision to be reverted, at least in the 7.0.0 branch. I have already reverted it locally in our FreeBSD project branch for importing llvm/clang 7.0.0. Hans, what is your opinion about this? -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180817/2f8a2fc7/attachment.sig>