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 920E63857004; Mon, 12 Sep 2022 11:21:47 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 920E63857004
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1662981707;
	bh=4cruAB/5t1y0NfnamaNydAOOyAFjaG13pgJ5aDzzzpA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=t3Gc6F2Vgx5gpjJqPpeBNjAqNbCmPqw5CVsWzbmaQFP6LBdy5gelyHyt8HpHJLKXS
	 O+lskvr0wB4p32KND/OchYt6m01azYoq4L/QKLoGrj22qelxUTpRYdr4F+DsQDgGtg
	 sZTHprsImAGlWaQlgUm95h9hbJwDKvBFuWK9ec2U=
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/106896] [13 Regression] ICE in
 to_sreal_scale, at profile-count.cc:339
Date: Mon, 12 Sep 2022 11:21:47 +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: 13.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-106896-4-qBcktK2nlz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106896-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106896-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=3D106896

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #1 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.or=
g> ---
The problematic line is:

  return bb->count.to_sreal_scale (ENTRY_BLOCK_PTR_FOR_FN (cfun)->count);

where bb->count is:

  {m_val =3D 0, m_quality =3D GUESSED_LOCAL}

and the entry block count is:

  {m_val =3D 0, m_quality =3D PRECISE}

So we fail the first assert here:

  /* Watch for cases where one count is IPA and other is not.  */
  if (in.ipa ().initialized_p ())
    {
      gcc_checking_assert (ipa ().initialized_p ());
      /* If current count is inter-procedurally 0 and IN is inter-procedura=
lly
         non-zero, return 0.  */
      if (in.ipa ().nonzero_p ()
          && !ipa().nonzero_p ())
        return 0;
    }
  else
    /* We can handle correctly 0 IPA count within locally estimated
       profile, but otherwise we are lost and this should not happen.   */
    gcc_checking_assert (!ipa ().initialized_p () || !ipa ().nonzero_p ());

But ipa() says:

  /* Return variant of profile count which is always safe to compare
     across functions.  */
  profile_count ipa () const
    {
      if (m_quality > GUESSED_GLOBAL0_ADJUSTED)
        return *this;
      if (m_quality =3D=3D GUESSED_GLOBAL0)
        return zero ();
      if (m_quality =3D=3D GUESSED_GLOBAL0_ADJUSTED)
        return adjusted_zero ();
      return uninitialized ();
    }

So it feels like the ipa() in to_sreal_scale is a speculative
=E2=80=9Ccould I compare this value across functions, if I had to?=E2=80=9D.

The bb->count computation quoted above is deliberately intraprocedural
rather than interprocedural.  In that context it doesn't really seem
relevant that one of the values could be compared across functions,
since that isn't what we're doing.

What's the right fix here?=