https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Hans-Peter Nilsson <h...@gcc.gnu.org>: https://gcc.gnu.org/g:5db1fa9bc69dd58ce2f93dd707d05efcfe89ffa8 commit r11-2682-g5db1fa9bc69dd58ce2f93dd707d05efcfe89ffa8 Author: Hans-Peter Nilsson <h...@axis.com> Date: Thu Aug 13 05:12:23 2020 +0200 gcc.dg/pr94600-5.c .. -8.c: Align struct t0 explictly, as a type, PR middle-end/94600 The bitfield-struct t0 in gcc.dg/pr94600-1.c ..-4.c is assigned to a pointer that is a (volatile-and-pointer-)cast literal, so gcc doesn't need to be otherwise told that the address is aligned. But, variants pr94600-5.c ..-8.c are assigned through a "volatile t0 *", and rely on the *type* being naturally aligned, or that the machine has non-strict-alignment moves. Unfortunately, systems exist (for some definitions of exist) where such structs aren't always naturally aligned, for example if it contains only (small) bitfields, even though the size is a naturally accessible size. Specifically, the mmix-knuth-mmixware port has only *byte* alignment for this struct. (If an int is added to the struct, alignment is promoted.) IOW, a prerequisite of the test is false: the struct doesn't have the same alignment as an integer of the same size. The effect is assignment in byte-size pieces, and the test fails. (For a non-volatile assignment, memcpy is called.) That's easily fixable by defining the type as having a specific alignment. This is also closer to the type in the original code, and also as the first variants aren't affected, no second thought or re-visit of pre-fixed compiler is needed. I don't plan to back-port this to gcc-10 branch however. I did sanity-check that the tests still pass on ppc64le-linux. gcc/testsuite: PR middle-end/94600 * gcc.dg/pr94600-5.c, gcc.dg/pr94600-6.c, gcc.dg/pr94600-7.c, gcc.dg/pr94600-8.c: Align t0 to 4-byte boundary.
