[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Richard Biener changed: What|Removed |Added Target Milestone|7.3 |7.4 --- Comment #8 from Richard Biener

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Matt Godbolt changed: What|Removed |Added CC||matt at godbolt dot org --- Comment #7

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 --- Comment #6 from Peter Cordes --- (In reply to Jakub Jelinek from comment #4) > But have just tried gcc 7.1.0 release and can't reproduce even there. Matt says the Compiler Explorer backend uses upstream release tarballs like

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 --- Comment #5 from Peter Cordes --- (In reply to Jakub Jelinek from comment #4) > Can't reproduce. It is true that we now emit the __atomic_load_16 call, but > that was intentional change Yup. >, and it can't be easily tail call, because the

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 --- Comment #3 from Peter Cordes --- Seems to be fixed in gcc7.2.0: https://godbolt.org/g/jRwtZN gcc7.2 is fine with -m32, -mx32, and -m64, but x32 is the most compact. -m64 just calls __atomic_load_16 gcc7.2 -O3 -mx32 output:

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |7.3

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |7.3 --- Comment #3 from Richard Biener

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |7.3 --- Comment #3 from Richard Biener

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 --- Comment #2 from Peter Cordes --- (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

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED