https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #0) > Hi, > ipa-fnsummary sets can_change_signature flag which determines whether we can > manipulate parameters of a given function. It tests: > > /* Type attributes can use parameter indices to describe them. */ > if (TYPE_ATTRIBUTES (TREE_TYPE (node->decl)) > node->can_change_signature = false > Which unfortunately triggers on many C functions now when we introduced the > access attribute. > > Updating happens in ipa-param-manipulation and we do have infrastructure how > to rewrite (suriving) old attributes to new ones, so we could support access > attribute updating (or always map to old indexes when using it). We do? I thought I would need to write it (together with recognizing parameters which we can safely update/ignore). > > I don't think possible warnings should inhibit useful optimizations and this > is a regression wrt compilers before the access attribute. I am having > patch to fix similar issue with fnspec attribute that can be safely removed > at signature change since we now can preserve info in ipa-modref. > > Martin, I wonder if if you would be OK with simply dropping the access when > function signature changes (which I can prepare patch for) or do you want to > dive into updating it? I would be OK with it but I don't think people who invested the energy into these new security warnings would. > > Once new fuction is created, for every new parameter there is > get_original_index accessor which returns original parameter index (if it > exists). This could be easily used to update access and drop those entries > that was really optimized out IMO Yeah. I guess that is the necessary thing to do.
