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 83B483858D35; Tue,  7 Feb 2023 11:34:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83B483858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675769645;
	bh=X1umeMeTipPNbXYMsSAe6g+arGVS0okK6DtiaV75+eU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=f9Kn/ijMCfAN8QOWd6i+jWmTmS9w2vmWrGsIFDOfozz+ahRrCZ+zPT5fd6HBqxn8R
	 HHp+FMpNAwezdLwPs3lLbI8lyjg1h2VnonnhTGKymO3tbHQjHHS3v47UuaqDP6kxiL
	 7/GawkyaBJG3yZ1ChWEOtUl2qlsZaJb4sriSV4Cw=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/106912] [13 Regression] ICE in
 vect_transform_loops, at tree-vectorizer.cc:1032 since
 r13-1575-gcf3a120084e94614
Date: Tue, 07 Feb 2023 11:33: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: rguenth 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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106912-4-NPu1oYYXzd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106912-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106912-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=3D106912

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
See https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607202.html and=
 the
reaction from Honza.(In reply to Jakub Jelinek from comment #10)
> Also, the other PR is about a function being made const late when it
> previously wasn't, while in this case it is being made non-const after it
> has been const before.
>   /* Drop pure/const flags from instrumented functions.  */
>   if (profile_arc_flag || flag_test_coverage)
>     FOR_EACH_DEFINED_FUNCTION (node)
>       {
>         if (!gimple_has_body_p (node->decl)
>             || !(!node->clone_of
>             || node->decl !=3D node->clone_of->decl))
>           continue;
>=20
>         /* Don't profile functions produced for builtin stuff.  */
>         if (DECL_SOURCE_LOCATION (node->decl) =3D=3D BUILTINS_LOCATION)
>           continue;
>=20
>         node->set_const_flag (false, false);
>         node->set_pure_flag (false, false);
>       }
> just looks completely wrong to me for const, which unlike pure attribute =
can
> be on both function types and on function declarations.  If we want calls=
 to
> const functions to actually not be treated as const when profiling, it can
> be only done by ignoring const everywhere if profile_arc_flag ||
> flag_test_coverage.  It even can't be just ignored for direct calls to
> defined functions, because calls can be indirect at first, without vops, =
and
> then fndecl propagated and turned into direct.  Or for IPA they can be
> defined in other TUs.

See https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607202.html and=
 the
reaction from Honza.=