From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 71ACD3858430; Thu, 30 May 2024 18:38:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 71ACD3858430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717094284; bh=UFmlmvfjpP6BOfbA/vlGs1xXaM/KhFkxFXITOAyRpII=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dDAOF2tlheuAcytY7p2fXIbJu6loEeoBtQvUj6GHAHX7CtpITs5yEi+eyF5SqcLDI qxov4HK1vrxuO9I8Qmw6qbivnPZETJFu/qz+Vo3qNYNtPf899RIE10KPOhh6HYixy0 D6TBW7N46LGRMREIeB+2RvCH0B+UTulyOYu1XWoQ= 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: Thu, 30 May 2024 18:38:03 +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 #27 from Peter Cordes --- (In reply to Hongtao Liu from comment #26) > (In reply to Hongtao Liu from comment #25) > > (In reply to Peter Cordes from comment #22) > > > Why are we adding an alignment requirement to _mm_storel_pd, the intr= insic > > > for MOVLPD? > > >=20 > > From Intel intrinsic guide[1], there's explict "mem_addr does not need = to be > > aligned on any particular boundary" for mm_store_sd, but not for > > _mm_storel_pd. > > [1] https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index= .html > >=20 > But for mm_loadl_pd, it also says no need for alignment, I need to confirm > with my peers if there's any specific purpose on that. > And yes, for <16-byte memory access, there's no alignment requirement > functionally. Interesting, yes some entries explicitly say the memory can be unaligned, s= ome don't. But I don't think we should read that as alignment required being t= he default if not stated. Every intrinsic that does require alignment explici= tly says so. (Like _mm_load_si128.) We could make the same argument in the ot= her direction, that if an alignment requirement isn't mentioned, we should assu= me there isn't one. And I already posted earlier about why we shouldn't assume C semantics base= d on the pointer type as Andrew Pinski had thought. Intel's intrinsic docs were originally written for ICC (classic), which takes intrinsics very literally= : an intrinsic in the C source will (almost?) always compile to the corresponding asm instruction. And presumably not optimizing based on pointer-alignment = UB even on a deref. And definitely not on strict-aliasing UB. So the C defaults for deref of a double* or __m64* shouldn't be assumed even when the docs don't say anything about alignment. They also don't mention aliasing but we know from Intel's examples of how to use intrinsics (I thin= k) that the load/store intrinsics are all may_alias accesses. Intel's current ICX compiler is based on LLVM which does care about aliasing and alignment UB when optimizing, but their intrinsic docs still read like they're thinking more in terms of asm than in terms of the C abstract machi= ne.=20 Probably they haven't been rewritten with that in mind since they implement them (in their own compilers) so they Just Work even when aliasing other ty= pes or without alignment.=