https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #22 from Peter Cordes <pcordes at gmail dot com> --- Why are we adding an alignment requirement to _mm_storel_pd, the intrinsic for MOVLPD? It was defined in terms of _mm_store_sd (which this patch correctly changes to remove the alignment requirement), so we're technically not *adding* an alignment requirement, rather keeping it from the old definition of _mm_store_sd. This is a bad thing; we should be removing the alignment requirement on it, too. That instruction is useless and should never be used in asm except for code-alignment reasons (1 byte longer than MOVLPS, same length as MOVSD, all three doing the same thing for the memory-destination form). But easy to imagine some code using that intrinsic to store an unaligned double into a byte buffer. IDK if there's any authoritative documentation from Intel on which intrinsics support unaligned pointers, but for intrinsics which are documented as corresponding to one specific instruction (unlike _mm_set), the sensible assumption would be that the intrinsic has the same alignment requirements as the instruction. For everything narrower than 16 bytes, that means no alignment requirement. I think most programmers would find it surprising if that wasn't the case, especially since GCC doesn't AFAIK document the intrinsics itself to specify anything else. (And with Intel intrinsics, I think they're all intended to allow aliasing, e.g. pointing a double* at a buffer also accessed with some struct type.) Also, should the type name double_u be changed to something with __ to avoid polluting the namespace? (In reply to GCC Commits from comment #19) > The master branch has been updated by Hu <hu...@gcc.gnu.org>: > > https://gcc.gnu.org/g:5967696c0f6300da4387fea5d102be5bc9f23233 > > commit r15-337-g5967696c0f6300da4387fea5d102be5bc9f23233 ... > (_mm_storel_pd): Add alignment requirement. > * config/i386/xmmintrin.h
