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 B27E33858CDB; Mon,  6 Feb 2023 09:56:49 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B27E33858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675677409;
	bh=VDn03jHJwiaMynfc1UT9JsuJWFBS3nmBeCqanE7QFdo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VUA8VP7Ghx4h6Iv+h0DLNZ1pXAvmYxVsnTBW6MrcvaXnV3jtDsOUxFIGqJ8XQ7j/7
	 7inXQ28bAw1EsR3eXUVYZdjkP39ukHdsk+A1jFuZgcvcx2HGYU0SxC3eiswsBo5VIg
	 T3oSgmL8PfPi6fID2yVwGjkklRQR6MKh134zGbf8=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a
 function containing an infinite loop from another thread depending on the
 optimization level
Date: Mon, 06 Feb 2023 09:56:49 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 12.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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-108658-4-W47rKwy5Qy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108658-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108658-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=3D108658

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The relevant optimization happens in invariant motion which applies
store-motion to

void * idle (void * ignored)
{
  long int PROF_edge_counter_1;
  long int PROF_edge_counter_2;

  <bb 2> [local count: 10631108]:

  <bb 3> [local count: 1073741824]:
  PROF_edge_counter_1 =3D __gcov0.idle[0];
  PROF_edge_counter_2 =3D PROF_edge_counter_1 + 1;
  __gcov0.idle[0] =3D PROF_edge_counter_2;
  goto <bb 3>; [100.00%]

producing

void * idle (void * ignored)
{
  long int __gcov0.idle_I_lsm.4;
  long int PROF_edge_counter_1;
  long int PROF_edge_counter_2;

  <bb 2> [local count: 10631108]:
  __gcov0.idle_I_lsm.4_7 =3D __gcov0.idle[0];

  <bb 3> [local count: 1073741824]:
  # __gcov0.idle_I_lsm.4_6 =3D PHI <__gcov0.idle_I_lsm.4_7(2),
__gcov0.idle_I_lsm.4_8(4)>
  PROF_edge_counter_1 =3D __gcov0.idle_I_lsm.4_6;
  PROF_edge_counter_2 =3D PROF_edge_counter_1 + 1;
  __gcov0.idle_I_lsm.4_8 =3D PROF_edge_counter_2;

  <bb 4> [local count: 1073741824]:
  goto <bb 3>; [100.00%]

that's not wrong I think.  With -fprofile-update=3Datomic that doesn't
happen but the atomic update call never gets a location assigned, instead
we rely on the stmt-begin/end notes here?

void * idle (void * ignored)
{
  <bb 2> [local count: 10631108]:

  <bb 3> [local count: 1073741824]:
  __atomic_fetch_add_8 (&__gcov0.idle[0], 1, 0);
  goto <bb 3>; [100.00%]=