On 13 May 2017, at 09:01, Jan Beich <[email protected]> wrote: > > Jonathan Gray <[email protected]> writes: > >> On Sat, May 13, 2017 at 02:22:30AM +0200, Jan Beich wrote: >> >>> "int" isn't large enough and lack of builtins only manifests at link time. >>> This was breaking build on FreeBSD 11.0 i386 with Clang 3.8.0. >>> >>> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function >>> `disk_cache_remove': >>> disk_cache.c:(.text+0x763): undefined reference to `__atomic_fetch_add_8' >>> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function >>> `cache_put': >>> disk_cache.c:(.text+0xabc): undefined reference to `__atomic_fetch_add_8' >>> disk_cache.c:(.text+0xec1): undefined reference to `__atomic_fetch_add_8' >>> c++: error: linker command failed with exit code 1 (use -v to see >>> invocation) >> >> You should be building with -march=i586 on i386 for CX8. > > -march=i586 doesn't help. Dimitry, could this be a Clang bug? > > $ cat a.c > #include <stdint.h> > int main() { > uint64_t n; > return __atomic_load_n(&n, __ATOMIC_ACQUIRE); > } > > $ clang40 -m32 -march=i586 a.c > /tmp/a-d984ec.o: In function `main': > a.c:(.text+0x21): undefined reference to `__atomic_load_8' > clang-4.0: error: linker command failed with exit code 1 (use -v to see > invocation)
Yes, this is in essence the same problem we uncovered some time ago with boost-libs in https://bugs.freebsd.org/216745, where we first noticed some weirdness in clang's handling of atomics on 32-bit x86. Upstream llvm/clang first tried to fix this properly in https://reviews.llvm.org/rL291477, but it got reverted just before 4.0.0 release, since it caused some other issues. There's still https://reviews.llvm.org/D29542 open for review, which is yet another attempt at fixing this. Though it will cause trouble for FreeBSD, since we don't have an atomic lib (see below). >> The diff is wrong as it will break other architectures, ie powerpc. > > And it's not broken already? -latomic isn't passed anywhere. FreeBSD doesn't have a libatomic, unfortunately. Until now, we have always weaseled through, and our gcc and clang versions have inserted cmpxchg8b's everywhere, even on CPUs where these are not supported. -Dimitry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
