From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 100DE3857836; Tue, 25 Aug 2020 12:37:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 100DE3857836 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1598359061; bh=k2TGqd67m6iDoXc3ZrYmC8isc60rsU5gI+G2rKwLZqQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=u3aEKK81pKALwDoDLsToLguCpSmIa/NmjTdBp6vl0FM1UOxoVTHklkFb1TpADl72X rsxLfotwvNrWUrBxqNaTdwZZ5JKND2yExV/7IW8uYdWUuNQpWn9ozqhETtTErsRIf5 mdiJwjwfYR/MfXTP2OHK3gjjBehx9ganc+QNpBPI= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/96729] [11 Regression] hang on x86_64-linux-gnu with `-g -O3` since r11-39-gf9e1ea10e657af9f Date: Tue, 25 Aug 2020 12:37:40 +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.0 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 12:37:41 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96729 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aoliva at gcc dot gnu.org, | |jakub at gcc dot gnu.org --- Comment #3 from Richard Biener --- I can't reproduce this. Well, -O3 -g takes way longer but that's because we elide the stores to a, b, d and e since the loop is endless and then we unroll it all ending up with a basic-block with just ~20000 useless debug stmts. So we now optimize as expected. -gno-statement-frontiers makes it also compiled fast. Now the question is whether we may want to do anything about a BB like [local count: 1804255]: [t.c:4:3] # DEBUG BEGIN_STMT [t.c:5:5] # DEBUG BEGIN_STMT [t.c:6:5] # DEBUG BEGIN_STMT [t.c:10:7] # DEBUG BEGIN_STMT [t.c:11:7] # DEBUG BEGIN_STMT [t.c:11:14] # DEBUG BEGIN_STMT [t.c:12:9] # DEBUG BEGIN_STMT [t.c:13:9] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> NULL [t.c:14:11] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> 0 [t.c:15:11] # DEBUG BEGIN_STMT [t.c:15:19] [t.c:15:15] [t.c:15:12] c[0][0] =3D 3; [t.c:13:23] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:11:22] # DEBUG BEGIN_STMT [t.c:11:14] # DEBUG BEGIN_STMT [t.c:12:9] # DEBUG BEGIN_STMT [t.c:13:9] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> NULL [t.c:14:11] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> 0 [t.c:15:11] # DEBUG BEGIN_STMT [t.c:13:23] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:11:22] # DEBUG BEGIN_STMT [t.c:11:14] # DEBUG BEGIN_STMT [t.c:12:9] # DEBUG BEGIN_STMT [t.c:13:9] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> NULL [t.c:14:11] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> 0 [t.c:15:11] # DEBUG BEGIN_STMT [t.c:13:23] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:11:22] # DEBUG BEGIN_STMT [t.c:11:14] # DEBUG BEGIN_STMT [t.c:12:9] # DEBUG BEGIN_STMT [t.c:13:9] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> NULL [t.c:14:11] # DEBUG BEGIN_STMT [t.c:14:13] # DEBUG g =3D> 0 ... [t.c:15:11] # DEBUG BEGIN_STMT [t.c:15:19] [t.c:15:15] [t.c:15:12] c[1][0] =3D 3; [t.c:13:23] # DEBUG BEGIN_STMT [t.c:13:16] # DEBUG BEGIN_STMT [t.c:11:22] # DEBUG BEGIN_STMT [t.c:11:14] # DEBUG BEGIN_STMT ... I understand that it is not as simple as simply killing adjacent DEBUG BEGIN_STMT stmts, keeping only the last?=