From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 6006E3857C51; Fri, 27 Jan 2023 15:15:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6006E3857C51
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1674832533;
	bh=k5OT9XFnvdqI3GzF0cAAbYvPI3XVgvZrl7DUlGHLI7o=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=va55Tv7j1iV0+zV1zx/P1kQC8CvrLlbUvdH4mDToMfj1jhjzUIW62vVUqrIOlgIdV
	 OPjV4mfzXpBTPU+DDhSMfwf3VPoxXriE5kfxZmryQ2LqgkXphU8ucQVuMVCP5x6cGP
	 vy8cXsoCRLdyfC3PppSkIxFp5Evy06WwL4G/SWgk=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/108552] Linux i386 kernel 5.14 memory
 corruption for pre_compound_page() when gcov is enabled
Date: Fri, 27 Jan 2023 15:15:32 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 11.3.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
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: 
Message-ID: <bug-108552-4-JkFNBcvWAq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108552-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108552-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108552

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> Ah, reading more comments, no - it probably doesn't.  Jakub correctly says
> that there seems to be a data race necessary to trigger this, so it doesn=
't
> seem to be a GCC issue?

Well, we could in -fprofile-update=3Dsingle (or perhaps in a new single-like
mode) mark the gcov artificial vars volatile or with some flag that would at
least cause reload not to reread values from memory.  The profiling would be
still racy, but at the expense of somewhat slower code (with volatile more,
with special flag less so) slightly less so (as it would e.g. prevent the
compiler from avoiding the rereads).=