From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3315E3858D32; Tue, 2 Jan 2024 14:40:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3315E3858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1704206458; bh=WTcxEsS+uqhB/pyOJ/kVXjrv42WG8CjSwj65uDddKAg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KPc+GrP10zEbD5Fg1Qh9Z2ArDsU833NsPPQAGW1AYDgyHXWSWhxVo2ITcSkRq+O8d DpD9Y0MHmS3KfvDDaszrBbD21QUAk+MLFzJqLkWZCuYvAQj2081KtPD+o4SL7LFYw6 nWMLi6Uvi+cU3WYyuy+0JaeLsQBIP+7uUn2YU6vg= From: "rearnsha at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 Date: Tue, 02 Jan 2024 14:40:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rearnsha at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: 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=3D113045 Richard Earnshaw changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rearnsha at gcc dot gnu.org --- Comment #20 from Richard Earnshaw --- (In reply to Andrew Pinski from comment #9) > This is almost definitely a valgrind issue. > We start with: > /* Align the source pointer. */ > misalign =3D (uintptr_t)s & 15; > p =3D (const uint8_t *)((uintptr_t)s & -16); > data =3D vld1q_u8 (p); >=20 >=20 > Which all other targets do too. >=20 > Basically this is how you realign the pointer and if don't depend on the > bytes that is not in the original pointer, then this is valid. >=20 > Does it work correctly without valgrind? Yes, for the first fetch, we align down to a 16-byte boundary and fetch the full 16 bytes. We then mask off the bytes that are before the real start of the buffer so that they cannot affect the result. So the code is safe, but valgrind has no real way of knowing this. Tricks like this wouldn't work with capability pointers, but we're not concerned about that here; even MTE (on aarch64) would be ok because the alignment used matches the tag granule size. So I'm pretty sure this is a false positive. But perhaps we should just disable the vectorized scanning when valgrind checking is enabled. Note that glibc implementations of str* functions can perform a similar tri= ck, but perhaps valgrind has special knowledge of such cases.=