From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 395483858D28; Mon, 4 Mar 2024 21:48:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 395483858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709588926; bh=KT+YaGiNi8ocaKtNvYJqJxN1zeGsqYYWCQ2UXRleEIg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rPKx0j9h6RpNsuGFf1jMsLsPNs5ubndhhguLJA2dmZNedZkq5RD+WI8CH6rQx8Ysm EW6u/upQaQuTfC1RBbPwdGIN/7AkhPiOBnYqDtd5VdPbzpa/eA9wWZDO6xXXOb8E2f 2DoidXuKdSpr9TRn+NVTD6xoNxH7COpuDdkW5WL4= From: "i at maskray dot me" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access Date: Mon, 04 Mar 2024 21:48:45 +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: 13.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: i at maskray dot me X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: cc 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=3D114217 Fangrui Song changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i at maskray dot me --- Comment #14 from Fangrui Song --- I agree with Jakub and Andrew. The relevant rules: C11 6.3.2.3 says > An integer may be converted to any pointer type. Except as previously spe= cified, the result is implementation-defined, might not be correctly aligne= d, might not point to an entity of the referenced type, and might be a trap= representation. > > A pointer to an object type may be converted to a pointer to a different = object type. If the resulting pointer is not correctly aligned for the refe= renced type, the behavior is undefined. ... C++ [expr.static.cast]p14 says of conversions from a misaligned pointer: > A prvalue of type =E2=80=9Cpointer to cv1 void=E2=80=9D can be converted = to a prvalue of type =E2=80=9Cpointer to cv2 T=E2=80=9D, where T is an obje= ct type and cv2 is the same cv-qualification as, or greater cv-qualificatio= n than, cv1. If the original pointer value represents the address A of a by= te in memory and A does not satisfy the alignment requirement of T, then th= e resulting pointer value is unspecified. ... Which is allowed to be an invalid pointer value, which the compiler is then permitted to give whatever semantics we like, such as disallowing it being passed to memcpy. --- memcpy is preferred for expressing an unaligned access. typedef struct dir_entry dir_entry_u __attribute__((aligned(1))); // In C++, there is an alternative: using dir_entry_u __attribute__((aligned(1))) =3D dir_entry; u64 gu(dir_entry_u *entry) { return entry->offset; }=