From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 82D8D3858C2C; Tue, 2 Jan 2024 16:25:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 82D8D3858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1704212723; bh=57cN9+gBgwDdQ9wrXZzcJ9U1NpQboxx/RrG23WabA/U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=H1X/+dCDOJfhscyQ99BovJeLOvnodCN8qg/sYyORgxUUXLpSiE+9SQ+sY1QacRfJ9 tDEtkIiRTSkTGJd19SLSZJbgtOf4DhoJYJ4tKocFiscD6bu2Q3anAMR/BhgyttCYLd SM4a3CfPqDWFL2y5xndW8iYEWT3LkoYGdf7Jqsik= From: "mark 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 16:25:22 +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: mark 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: 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 --- Comment #25 from Mark Wielaard --- Note comment #16 which explains that valgrind seems to translate this large read into smaller chunks. Which most likely causes memcheck to flag the (la= st) 8 bytes read as fully invalid. See --partial-loads-ok=3D [default: yes] Controls how Memcheck handles 32-, 64-, 128- and 256-bit naturally aligned loads from addresses for which some bytes are addressable and others are not. When yes, such loads do not produce an address error. Instead, loa= ded bytes originating from illegal addresses are marked as uninitialised, and t= hose corresponding to legal addresses are handled in the normal way. When no, loads from partially invalid addresses are treated the same = as loads from completely invalid addresses: an illegal-address error is issued, and the resulting bytes are marked as initialised. It would be helpful to see if someone with arm knowledge (and valgrind VEX knowledge) can see if there is a better translation of the vld1 instruction= so that it is one big read. That way memcheck at least has a chance of detecti= ng that the part that is invalid isn't actually used. See=20 https://sourceware.org/cgit/valgrind/tree/VEX/priv/guest_arm_toIR.c#n8383 But maybe there is no good/natural translation of these vector loads that w= ould help memcheck see it is a valid read and only the defined bytes are used.=