From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 17E7B385802A; Mon, 18 Dec 2023 17:10:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 17E7B385802A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1702919420; bh=rKVFUUDeRr7pZS2119yQqbttFy8X8f16aiwAS7ofVDg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QU50qS+YyDekQKoJ6/0BidpZ/o97gQfnU0AJMNI/CoHbxkec43zezcUmpCVnI2vXE Zcc0I+w5NRGLVolsGzCMGzABmJay1ooUGUZZvETRC2Uhi+CIVvPvSweJYnLcRdgwIt ra22/FEFR1CKIF2m/nO8G4lBeM79Jgex0hJ1BxB4= From: "juki at gcc dot mail.kapsi.fi" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee Date: Mon, 18 Dec 2023 17:10:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 8.4.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: juki at gcc dot mail.kapsi.fi 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: resolution 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=3D113025 juki at gcc dot mail.kapsi.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |FIXED --- Comment #2 from juki at gcc dot mail.kapsi.fi --- Unfortunately alignment of the cast type was not causing this issue. I changed all calls that were defined in GCC headers to use __m128i_u or __m128d_u types to use those types before unaligned intrinsic. For example LOAD_SI128 macro looks like the following: #define LOAD_SI128(ptr) \ ( ((uintptr_t)(ptr) & 15) =3D=3D 0 ) ? _mm_load_si128((__m128i*)(pt= r)) : _mm_loadu_si128((__m128i_u*)(ptr)) My changes only changed the debug information locations but did not lead to= the generation of different kind of load operations. In fact, generated assembly was identical outside of debug line information changes: $ diff -u0 orig.s fixed.s|grep movdq| wc 0 0 0 But if aligned loads are removed completely as an option and only unaligned loads (even with the wrong intrinsic type) are used, no invalid aligned loa= ds are generated and assembly changes significantly regarding movdq* instructi= ons: #define LOAD_SI128(ptr) \ ( 0 ) ? _mm_load_si128((__m128i*)(ptr)) : _mm_loadu_si128((__m128i*)(ptr)) diff -u0 orig.s align-loads-removed.s|grep movdq| wc 11001 44004 263376 Above code fixes all our invalid instruction generation while only using correct types does not. While I can't share the related sources, I could still try to run different tests locally to see what is be causing the issue. What could I do next to = help solve this as I do have reliable test cases to work with.=