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 347AD3858CD1; Tue, 19 Mar 2024 15:41:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 347AD3858CD1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1710862872;
	bh=M+uARM/WUz6VJdOSRtKAKXVg6ea6zIgFqO7p7TXpQVE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nfcQwn7YzSNrwZHxxyhyjhZVjx5jJVuPqc4lQAc/IDvPggpnJdo0h+2/N2hJfYSye
	 bU7+81IyeQyORgGcX9M/3/ALJkrjiVNhjQMwh/BOWzxKNhJugmqL+9BLL/QaDX/7jz
	 a156y4DAL7YAKDL1uL3PLdhZbTPfQrwf6c4RZxQc=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/109596] [14 Regression] Lots of guality testcase
 fails on x86_64 after r14-162-gcda246f8b421ba
Date: Tue, 19 Mar 2024 15:41:11 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: testsuite-fail, wrong-debug
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109596-4-sIxN0N41I6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109596-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109596-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=3D109596

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #4)
> The change makes loop iteration estimates more realistics, but does not
> introduce any new code that actually changes the IL, so it seems this mak=
es
> existing problem more visible.  I will try to debug what happens.

Yeah, I didn't see any debug info handling in that commit, so wouldn't surp=
rise
me if it was something latent before, or something where ch now needs to do=
 a
better job.
All I can see from the dumps is that before ch2 the debug stmt placements w=
ere
reasonable both for b and j, b 0 at the very start and after SSA_NAME def s=
tmts
which update it to a new value for the var (e.g. after PHI at the start of =
loop
body,
or after increasing the IV).
Before r14-162 ch2 used to do weird stuff with them - duplicating
  # DEBUG b =3D> 0
  # DEBUG b =3D> 0
at the start, after ++j:
  # DEBUG j =3D> j_9
  # DEBUG j =3D> j_9
after ++b:
  # DEBUG b =3D> b_7
  # DEBUG b =3D> b_7
and (the perhaps only reasonable change adding
  # DEBUG j =3D> 0
after the b PHI, though not really necessary as it has unconditional goto to
the header with PHI after which it is set to something else).
But, newly ch2 in addition to the useless duplicate of b =3D> 0, j =3D> j_9=
 and b
=3D> b_7
removes the most important debug stmts (
  # DEBUG j =3D> j_2
and
  # DEBUG b =3D> b_1
after the PHIs) and adds wrong-debug debug stmts elsewhere - the
  # DEBUG j =3D> 0
and
  # DEBUG b =3D> 0
in random incorrect places.=