This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __HAVE_64B_ATOMICS and alignment
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 18 Apr 2017 22:12:57 +0000
- Subject: Re: __HAVE_64B_ATOMICS and alignment
- Authentication-results: sourceware.org; auth=none
- References: <430bd9b7-a6fd-7247-7b60-965bd0486bbf@redhat.com> <1480333887.7146.1635.camel@localhost.localdomain> <a70fe786-4cfd-278f-7743-32e581c5af55@redhat.com>
On Thu, 13 Apr 2017, Florian Weimer wrote:
> On 11/28/2016 12:51 PM, Torvald Riegel wrote:
> > > This means that for an LP32 architecture such as i686 which could
> > > conceivable provide 64-bit atomics, we might try to perform an atomic
> > > operation on a potentially misaligned uint64_t value.
> > i686 has no 64b atomic loads or stores.
>
> double loads and stores via the FPU are atomic, and they preserve all bit
> patterns. (Starting with the Pentium, the FPU was sometimes used to implement
Note that only works for *integer* loads and stores (fild / fistp). You
can't use float or double loads and stores for arbitrary bit patterns
because if the bit patterns look like signaling NaNs, they'll be converted
to (long double) qNaNs, the "invalid" exception will be raised and the bit
pattern will not be preserved when the valid is stored back from the FPU.
--
Joseph S. Myers
joseph@codesourcery.com