https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581
--- Comment #6 from James Carlson <carlsonj at workingcode dot com> --- "Partial strict" seems a stretch to me. The SSE2 instructions are relatively new, as is their use by the optimizer. That makes this a surprising change in behavior, particularly given that a vast quantity of software has been written assuming that x86 supports unaligned access directly. Nobody's arguing that the general behavior of the source code in question is anything other than "undefined." That's obviously the case. However, it is also a fair argument to say that alignment behavior for x86 has been very well known and understood ... right up to this point, where this optimization breaks it. It would be impractical (in the extreme) to use cast-align=strict. In nearly all cases where this macro is used, we're targeting x86 instructions that handle the request perfectly well. There is no actual bug, in source or runtime, and a warning would just be lost in the noise. Treating all usages as "bugs" in the code is just absurd, as is forcing x86 code to go through the painful paths that most RISC code (the other side of the #ifdef around that #define) uses merely because someone now calls x86 "partial strict." There's just one narrow, rare case where the problem happens -- loops that can be optimized by the use of SSE2 instructions -- and it's *VERY* hard to defend at the source level. Perhaps the ideal solution for those of us suffering through this disaster would be a new option that tells the optimizer NOT to assume alignment based solely on pointer type when targeting SSE2. (There are clearly cases where the alignment is known to be good, as when getting the value from a function [such as malloc] that always returns good alignment, or referencing a static or auto variable. But just seeing "short *" in the source would not be enough.)
