Date: Fri, 30 Aug 2019 20:48:22 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230888] Missing 64 bit atomic functions for i386 (libatomic) Message-ID: <bug-230888-29464-LIDByQUIO1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230888-29464@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888 --- Comment #12 from Dimitry Andric <dim@FreeBSD.org> --- This issue has now come up again with the import of llvm 9.0.0 (which is ongoing). Upstream has committed the following change, https://reviews.llvm.org/rL356631 ("[X86] Add CMPXCHG8B feature flag. Set it for all CPUs except i386/i486 including 'generic'. Disable use of CMPXCHG8B when this flag isn't set") Before that change, clang actually had a bug, in the sense that it *did* sometimes generate cmpxchg8b instructions on i486, which is still our default target CPU. This saved us from most cases where otherwise __atomic_xxx function calls would be inserted. However, now this bug has been fixed, so it will always use function calls for atomic 64 bit operations. Upstream, I have had to report that it cannot even do the unit tests for compiler-rt 9.0.0 anymore, since that already runs into link errors about __atomic_xxx functions: https://bugs.llvm.org/show_bug.cgi?id=42892 Realistically, the best way forward in the short term is to raise the default target CPU for FreeBSD to i586 or even i686, so cmpxchg8b is supported. Specifically, because I do not think it is very realistic to run modern FreeBSD on real i486-class hardware. Not to mention that that is basically museum class hardware now. :-) -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230888-29464-LIDByQUIO1>