[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.

[carlsonj at workingcode dot com]

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.)