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/> References: <bug-230888-29464@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=3D230888 --- 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 defau= lt 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=3D42892 Realistically, the best way forward in the short term is to raise the defau= lt target CPU for FreeBSD to i586 or even i686, so cmpxchg8b is supported.=20 Specifically, because I do not think it is very realistic to run modern Fre= eBSD on real i486-class hardware. Not to mention that that is basically museum class hardware now. :-) --=20 You are receiving this mail because: 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-230888-29464-LIDByQUIO1>