This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17403] atomic_full_barrier is incorrect for x86 and x86_64
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 17 Sep 2014 16:05:30 +0000
- Subject: [Bug libc/17403] atomic_full_barrier is incorrect for x86 and x86_64
- Auto-submitted: auto-generated
- References: <bug-17403-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17403
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
This could use some explanation as to why you think it's wrong. In the original
x86 memory model, there is absolutely no need for memory barriers (though
compiler barriers are of course needed). My understanding is that there are
some newer instructions available which can optionally relax memory ordering,
but it's not clear to me if they would be used by the compiler in any way that
would necessitate having mfence or similar instructions alongside atomics. If
so, I believe this is an ABI incompatibility issue, since the atomics in use
may be built for i486 (where they don't have access to any explicit barrier
instruction). So from that standpoint some clarification is really needed to
determine if we have a bigger problem on our hands...
--
You are receiving this mail because:
You are on the CC list for the bug.