This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes
- From: "peter at cordes dot ca" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 23 May 2017 07:51:25 +0000
- Subject: [Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes
- Auto-submitted: auto-generated
- References: <bug-80837-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837
--- Comment #2 from Peter Cordes <peter at cordes dot ca> ---
(In reply to Richard Biener from comment #1)
> GCC 8 generates a __atomic_load_16 call for me while GCC 6 does
>
> lock cmpxchg16b (%rdi)
That's expected. See https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02344.html
for the reason. (Apparently the plan is for gcc7 to call libatomic, to make it
possible to change the implementation sooner in the future if that's deemed
appropriate, even in ways that breaks compat with code that inlines lock
cmpxchg16b.)
The bug here is that gcc7.1.0 goes berserk after the library call, but gcc8
doesn't. I haven't tested on any other gcc7 versions.