From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CC45A385351A; Sat, 28 Oct 2023 10:04:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC45A385351A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1698487463; bh=Ea1Jo2prTZ0dJTl9tSb9yb2rt0EVl4JwRJEcSP4OVhA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GCLekQ0nhhgC5Yj91NnX5WVB+M8/C4IPZTyXndB2AxvAAhMUbHC0ihJcdnhIrz/jB yx6fbTUrTP6nv62qRQpE0SaSIOCZn6PvufLbk7YkWFK0uAL1r0IZPFrP3lkY99Yisf snW5fi2vKLRLkoAIoF4Ghf7leJU64uOwqtsduOGE= From: "post+gcc at ralfj dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/32667] block copy with exact overlap is expanded as memcpy Date: Sat, 28 Oct 2023 10:04:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: post+gcc at ralfj dot de X-Bugzilla-Status: NEW 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=3D32667 post+gcc at ralfj dot de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |post+gcc at ralfj dot de --- Comment #23 from post+gcc at ralfj dot de --- > Is glibc community ready to provide such guarantee? This is indeed a key question here I think. Currently GCC makes assumptions that *even the libc produced by the same project* does not document as stab= le guarantees. That's rather dissonant. The GNU project should at least within itself come to a proper conclusion on the question of whether memcpy should= be UB or not when both pointers are equal. Right now we have everyone pointing= at everyone else, and users are left in the rain with their valgrind errors. Ideally of course the C standard would be updated to ensure that slowly but steadily, the memcpy contract is updated to match reality. That will take a while, but given that this issue was filed 16 years ago (!), there clearly would have been enough time. (If someone does, please join forces with the clang people that are interested in getting C updated: https://reviews.llvm.org/D86993#4585590). But GNU controls glibc so there's not really any excuse for not updating th= ose docs, I think? glibc making such a move would be a great step towards convincing valgrind and the C committee that memcpy should have defined behavior when both pointers are equal.=