On Wed, Nov 19, 2025 at 02:00:03PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 19, 2025 at 01:49:39PM +0100, Richard Biener wrote:
> > Then, there is DECL_NONADDRESSABLE_P on a FIELD_DECL which for,
> > say
> >
> > struct{
> > int len;
> > char *data;
> > };
> >
> > could say that 'len' cannot have its address taken and thus the 'data'
> > member
> > cannot point to it. Not sure if it's possible to take the address of
> > the length field
> > of a std::string though, this mechanism isn't specific enough to only
> > disallow
> > 'data' from pointing to 'len'. DECL_NONADDRESSABLE_P is used by Ada
> > (as is TYPE_NONALIASED_COMPONENT).
>
> Makes me wonder if we couldn't set DECL_NONADDRESSABLE_P on private
> FIELD_DECLs in classes where none of the methods take address of it and
> either it doesn't have friends, or none of the friends take address of it
> either. Though, I guess C++26 reflection breaks that assumption, one can
> always use
> &the_class_obj.[: std::meta::members_of (^^the_class,
> std::meta::access_context::unchecked ())[N] :]
> to bypass the access checking and still take the address of it.
Though perhaps that could be handled by clearing the DECL_NONADDRESSABLE_P
flag again if that FIELD_DECL is spliced.
Jakub
