From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CC9FC3858C33; Tue, 13 Sep 2022 08:51:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC9FC3858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663059062; bh=ulzzn2RYFe3X7mhB18Hhvt42Z6vBhZBSgHCwyo1JDbI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wk7nKW3Z9TQhViHCYB6+I8rLZB71ex4ktQoCC8atbvp0ZLN/BKTLcAJafafEavy4J f5ufHtDKUBf3FUMJ7weTdCvx/OgzP1lVwp6RomeHZ2BNDzfKsuXxXp1YX25fP1Pfrc uLJVt3NROFGNwvrE3/zPT+dmeg08mmnVHwISLRo4= From: "rguenth at gcc dot 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, 13 Sep 2022 08:51:02 +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: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106912 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #4 from Richard Biener --- static tree handle_pure_attribute (tree *node, tree name, tree ARG_UNUSED (args), int ARG_UNUSED (flags), bool *no_add_attrs) { if (TREE_CODE (*node) =3D=3D FUNCTION_DECL) { tree type =3D TREE_TYPE (*node); if (VOID_TYPE_P (TREE_TYPE (type))) warning (OPT_Wattributes, "%qE attribute on function " "returning %", name); DECL_PURE_P (*node) =3D 1; /* ??? TODO: Support types. */ } else { warning (OPT_Wattributes, "%qE attribute ignored", name); *no_add_attrs =3D true; } meh. I also question that we clear const/pure after instrumenting. We don't do that for other instrumenting and it's only done for functions with definitions but not functions in other (profile instrumented) TUs. Edge counters do not alias anyway so that leaves for example __gcov_time_profiler_counter which is updated like # VUSE <.MEM_14> PROF_time_profile_8 =3D __gcov_time_profiler_counterD.2013; PROF_time_profile_9 =3D PROF_time_profile_8 + 1; # .MEM_15 =3D VDEF <.MEM_14> __gcov7.fooD.2016[0] =3D PROF_time_profile_9; # .MEM_16 =3D VDEF <.MEM_15> __gcov_time_profiler_counterD.2013 =3D PROF_time_profile_9; the counter is public, external and static (eh?). We do eventually IPA inline profile instrumented functions, but at least the above seems to be at function end only. That said, the const clearing doesn't have any effect, only the pure one has. It's possible to "fixup" in the vectorizer here but that's a hack for the general inconsistency. The vectorizer can also build a const qualified function type variant for the call fntype which might be a better fit but then the simd clones use the exact same counters as the original function which might or might not be intended ... Honza - any comments on the pure/const difference for profile instrumented code here? Do we need to "fix" the const case or can we drop the pure/const state changes? It depends on that what the correct fix in the vectorizer is.=