https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87054
Bug ID: 87054 Summary: misaligned asm output is turned into dereferenced pointer-to-aligned Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Depends on: 80334 Target Milestone: --- This bug came up while attempting to trigger the bug 80334, that was suspected to be latent in earlier versions. I managed to trigger the latent problem with a variant of the testcase below, but attempting to further minimize it, I found a way to trigger it even in GCC 8 and trunk: #ifndef T # define T long #endif #ifndef R # define R "r" #endif typedef T A; // #define T to long or __int128 struct B { char d; A c; } __attribute__((packed)); B b[50]; // many elements to avoid loop unrolling int main () { for (int i = 0; i < sizeof(b) / sizeof(*b); i++) { asm ("" : "+" R (b[i].unpacked)); // #define R to "r" on ppc or "x" on x86_64 } } The gimplifier introduces a pointer to the misaligned field for the asm output, discarding the information about the misalignment, and that pointer is dereferenced as if the object was aligned. There is a (broken) patch in that bug that works around the problem, but that fails to build libstdc++-v3 (unbound template names). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334#c12 FTR, the testcase that exercises the bug in older compilers, before the fix was backported, has a "manual reload" of the asm operand, compared with the above: auto r = b[i].unpacked; // aligned access to unaligned address asm ("" : "+" R (r)); // #define R to "r" on ppc or "x" on x86_64 b[i].unpacked = r; // pretend the loop has externally-visible effects Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334 [Bug 80334] [5 Regression] Segfault when taking address of copy of unaligned struct