https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 12 Apr 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jakub at gcc dot gnu.org, > | |jason at gcc dot gnu.org, > | |mpolacek at gcc dot gnu.org > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > I think the middle-end could figure this out by itself, such PARM_DECLs or > RESULT_DECLs > are DECL_BY_REFERENCE and TREE_ADDRESSABLE (TREE_TYPE (TREE_TYPE > (parm_or_decl))). We currently require an additional TYPE_RESTRICT on the pointer but do not require TREE_ADDRESSABLE. Do you say TREE_ADDRESSABLE provides the same guarantees as TYPE_RESTRICT here? > I think that means that if one calls a function with two arguments the two > arguments won't alias: > struct S { S (); ~S (); S (const S &); int s; }; > void > foo (S a, S b) > { > } > void > bar (S c) > { > foo (c, c); > } > Inside of the function one can take address of such a parameter as many times > as one wants and dereference through that of course. But I think one can > assume that when the > function is called, the argument (i.e. the address of the object in the > caller) > isn't stored anywhere else. I'd prefer if the frontend is explicit about this. What about S foo (S a) { return a; } can the return object alias the argument?
