Date: Fri, 03 Feb 2017 18:34:44 +0000 From: bugzilla-noreply@freebsd.org To: office@FreeBSD.org Subject: [Bug 216745] devel/boost-libs: atomics are broken with clang 4.0 on i386 Message-ID: <bug-216745-25061-ubDSFrdger@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-216745-25061@https.bugs.freebsd.org/bugzilla/> References: <bug-216745-25061@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216745 Dimitry Andric <dim@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org, | |kib@FreeBSD.org --- Comment #7 from Dimitry Andric <dim@FreeBSD.org> --- (In reply to Jan Beich (mail not working) from comment #4) > Dimitry, can you bisect or check if https://reviews.llvm.org/D28213 caused > the above behavior? I'm not sure how to fix Boost... I don't think we should fix Boost, as gcc on i386 also seems to set __GCC_ATOMIC_LLONG_LOCK_FREE to 1 on FreeBSD: $ gcc6 -v Using built-in specs. COLLECT_GCC=3Dgcc6 =20=20=20 COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc6/gcc/i386-portbld-freebsd12.0/= 6.3.0/lto-wrapper Target: i386-portbld-freebsd12.0 Configured with: /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/configure --disable-multilib --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc6 --libexecdir=3D/usr/local/libexec/gcc6 --program-suffix=3D6 --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local --with-gxx-include-dir=3D/usr/local/lib/gcc6/include/c++/ --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports Collection' --with-system-zlib --disable-libgcj --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local --localstatedir=3D/var --mandir=3D/usr/local/man --infodir=3D/usr/local/info/gcc6 --build=3Di386-portbld-freebsd12.0 Thread model: posix gcc version 6.3.0 (FreeBSD Ports Collection) $ gcc6 -dM -E -x c /dev/null | grep __GCC_ATOMIC_LLONG_LOCK_FREE #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 I have posted a similar comment on the LLVM review:=20 https://reviews.llvm.org/D28213#665967 but since it is already committed, I might have to open an upstream bug rep= ort. I would like to have a thorough explanation though. Maybe on Linux, there are only 32 bit x86 arches left that support CMPXCHG8= B?=20 I think we still support those, but we don't have __atomic_xxx_8 functions = in our libs to handle the cases where there isn't hardware support. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216745-25061-ubDSFrdger>