[Bug 216745] devel/boost-libs: atomics are broken with clang 4.0 on i386

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216745

Dimitry Andric <dim at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emaste at freebsd.org,
                   |                            |kib at FreeBSD.org

--- Comment #7 from Dimitry Andric <dim at 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=gcc6
   
COLLECT_LTO_WRAPPER=/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=/usr/local/lib/gcc6
--libexecdir=/usr/local/libexec/gcc6 --program-suffix=6
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc6/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --disable-libgcj --enable-languages=c,c++,objc,fortran
--prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/info/gcc6 --build=i386-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: 
https://reviews.llvm.org/D28213#665967

but since it is already committed, I might have to open an upstream bug report.
I would like to have a thorough explanation though.

Maybe on Linux, there are only 32 bit x86 arches left that support CMPXCHG8B? 
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.