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 E3D663858C83; Wed, 22 Feb 2023 20:51:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E3D663858C83
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677099102;
	bh=BBIFXHRGNLQEUUziYp5LA7Zq8Akkqyj9NZymFVFkRT8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=bI3281RbYowC9C0OZW2aYvp9TIj3/xwHhtBiEmRVMiWWDpgXGRe0O5fFXLOgU4ODw
	 gxpDtE/2BKdjfiYGTV0Z/RY+92Qej60OakqYFLM9xjA84PoXGAk2Zt3NN4OlPrEOPn
	 pNH83OAvp+zJ2UgeLmHJuAipELo2iFXAwocHh2S0=
From: "mpolacek 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:51:42 +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: mpolacek 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-KoXysIx0qS@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 #14 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> (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);
>=20
> 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 el=
se.
> To avoid testing it in every iteration you could have a hash_set<tree> *p=
set
> temporary initialized based on c_dialect_cxx () to NULL or data and then
> just use it in the loop.

Yeah, in C++ I get a crash in check_complete_insertion anyway.  I don't rea=
lly
see why but best to limit it to C.=