From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B61AC3858C78; Wed, 29 May 2024 18:45:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B61AC3858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717008342; bh=t/3eR/C+BRpdglupr+stAua13Q2biaOlEiFCrM+En2I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=arJUh0yLPIBWs9ENf9YA5cEmmBo3bCRQctg5sG0DURvIihLvSvJPy0lIXLvvWM5cl w6r1NvWB7efS+NF+UccdIuYVcFBcEOKiDHGV9F9utB3RuVbwa9FSbyvOYoaekFCv8n iOe74pC2STWkAwL9s8PybG3cXEqaNjwXfc/6pydg= From: "pcordes at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/84508] Load of misaligned address using _mm_load_sd Date: Wed, 29 May 2024 18:45:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 6.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pcordes at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84508 --- Comment #22 from Peter Cordes --- 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 intrinsi= cs 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 a= void polluting the namespace? (In reply to GCC Commits from comment #19) > The master branch has been updated by Hu : >=20 > https://gcc.gnu.org/g:5967696c0f6300da4387fea5d102be5bc9f23233 >=20 > commit r15-337-g5967696c0f6300da4387fea5d102be5bc9f23233 ... > (_mm_storel_pd): Add alignment requirement. > * config/i386/xmmintrin.h=