From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 01ECC3858405; Mon, 15 Nov 2021 21:02:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 01ECC3858405 From: "hubicka at kam dot mff.cuni.cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied Date: Mon, 15 Nov 2021 21:02:19 +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: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at kam dot mff.cuni.cz X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Mon, 15 Nov 2021 21:02:20 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103223 --- Comment #8 from hubicka at kam dot mff.cuni.cz --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103223 >=20 > --- Comment #5 from Martin Sebor --- > (In reply to Martin Jambor from comment #4) > > (In reply to Jan Hubicka from comment #0) > ... > > > Martin, I wonder if if you would be OK with simply dropping the acces= s when > > > function signature changes (which I can prepare patch for) or do you = want to > > > dive into updating it? > >=20 > > I would be OK with it but I don't think people who invested the energy > > into these new security warnings would. >=20 > I replied earlier on gcc-patches: I've always intended the access attribu= te to > eventually benefit optimization so please feel free (and encouraged :) to= use > it > for that purpose. The idea behind it was not just to catch bugs but also= to > enable optimizations based on the expectation that those bugs will have b= een > fixed. (This has to be done carefully since the attribute is also implic= itly > added in contexts where relying on it wouldn't correct for optimization; = the > attirbute API makes it possible to distinguish these cases.) Is there some summary of what information the access attribute holds in addition to what we have in fnspec (which is used for the optimization)? >=20 > By dropping the attribute in IPA passes we would not only give up on dete= cting > the bugs the IPA transformations expose but also on the optimization > opportunities they might open up. Yep, I hope it is not too hard to write code updating the attribute after transformation. We drop the attribute only when we actually do some change on function parameters. ipa-modref solves similar problem of updating the modref summaries after changes. What I do is to simply compute map translating old parameter indexes to new via: clone_info *info =3D clone_info::get (node); FOR_EACH_VEC_SAFE_ELT (info->param_adjustments->m_adj_params, i, p) { int idx =3D info->param_adjustments->get_original_index (i); if (idx > (int)max) max =3D idx; } auto_vec map; map.reserve (max + 1); for (i =3D 0; i <=3D max; i++) map.quick_push (-1); FOR_EACH_VEC_SAFE_ELT (info->param_adjustments->m_adj_params, i, p) { int idx =3D info->param_adjustments->get_original_index (i); if (idx >=3D 0) map[idx] =3D i; } and then I simply rewrite old parameter indexes to new and drop parts of info that uses parameters that was either removed or replaced by scalars/components. Similarly we can do for access attribute.=