https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040
Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #10) > (In reply to Martin Liška from comment #9) > > Thanks Jakub for your thoughts. I was also thinking about simple approach > > similar to what we do for use-after-scope in situations where there's a > > usage of IFN_ASAN_POISON. In that case we generate a 'shadow' variable > > that's poison/unpoisoned, etc. We can come up with automatic variables to > > which we assign an addressable PARM_DECL and then these variables will be > > normally protected with red zones. I can imaging bigger performance gap, but > > it can be quite easily doable I guess? > > That would work too. If doing it this way, it would be desirable to do it > late in the GIMPLE pass queue, e.g. in the sanopt pass, for the > TREE_ADDRESSABLE PARM_DECLs that don't have TREE_ADDRESSABLE types (those > are passed by invisible reference) create the DECL_ARTIFICIAL VAR_DECLs, > have them TREE_ADDRESSABLE, add > code to copy the PARM_DECLs to those vars at the beginning of the function, > clear TREE_ADDRESSABLE on the PARM_DECLs and remap all uses of the > PARM_DECLs except the newly added ones to the new VAR_DECLs. Not sure if > the PARM_DECLs should have DECL_VALUE_EXPR pointing to the VAR_DECLs (e.g. > for debug info purposes), and whether the artificial VAR_DECLs should be > added to some BLOCK_VARS or not. Good. I will implement that in this stage1 ;)