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 C20B73858D33; Wed, 22 Feb 2023 20:46:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C20B73858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677098811;
	bh=zM2iffooijVMECj3ydUXQkhnEM8VK/7aNAj2j/RC7ew=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=RVKNNaN93tzmg8I0QT2tpY/nabccdvy7lxA+f79aNcdss+ohWQ8tau8i7Rwfx56ue
	 WdqsggExNf2qJuW5+GXwBouMzmvgSNJ+EiuOdq42iOGv/iqpKtWq94N+eNeyF7qSOO
	 C2EshxraMSTNvNByezUWJtdT+ywf+tINmyhHs+3A=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/108880] [11/12/13 Regression] slow compilation with
 "-fsanitize=undefined"
Date: Wed, 22 Feb 2023 20:46:51 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: compile-time-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108880-4-cvkr298ef2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108880-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108880-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=3D108880

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #12)
> Sure, it worked for the testcase because the STATEMENT_LIST only had two
> stmts.  I'm testing:
>=20
> --- a/gcc/c-family/c-gimplify.cc
> +++ b/gcc/c-family/c-gimplify.cc
> @@ -516,7 +516,8 @@ c_genericize_control_stmt (tree *stmt_p, int
> *walk_subtrees, void *data,
>           tree t =3D tsi_stmt (i);
>           if (TREE_CODE (t) !=3D DEBUG_BEGIN_STMT && nondebug_stmts < 2)
>         nondebug_stmts++;
> -         walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
> +         walk_tree_1 (tsi_stmt_ptr (i), func, data,
> +              static_cast<hash_set<tree> *>(data), lh);

I'd limit this change to !c_dialect_cxx () only, I'm afraid if it is done
for C++ too, then cp_genericize_r won't then walk into those trees later on=
 and
could avoid replacing there something important.  While for C, there is
walk_tree solely for the purposes of c_genericize_control* and nothing else.
To avoid testing it in every iteration you could have a hash_set<tree> *pset
temporary initialized based on c_dialect_cxx () to NULL or data and then ju=
st
use it in the loop.

>           if (TREE_CODE (t) !=3D DEBUG_BEGIN_STMT
>           && (nondebug_stmts > 1 || TREE_SIDE_EFFECTS (tsi_stmt (i))))
>         clear_side_effects =3D false;=