https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 23 Feb 2021, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117 > > --- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> --- > So is Jakub wrong in comment 5 when he suggests that this should "lose" the > __restrict__ qualification? > > _Tp* __p (__a._M_data); Yes. __p is clearly based on __a._M_data and thus it can be used to access data pointed to by the restrict qualified __a._M_data which in turn means we can, if we prove value equivalence, place the same restrictions on accesses via __p as we can on accesses via __a._M_data. It would be way more awkward implementation-wise if we couldn't do that. > Is there a better way to drop that qual so that we can assign something to the > elements of __a._M_data that aliases itself? > > Presumably this would be guaranteed to work? > > _Tp* __p (__a._M_data); > for (size_t __i = 0; __i < __n; ++__i, ++__p) > { > _Tp __tmp = __e[__i]; > *__p = __tmp; > } That's no different. There's no way to lose restrict qualification but to obfuscate the code in a way to make the compiler not see the "based-on" relation of __a._M_data and the pointer used to access the data. Passing __a by reference should also run into limitations of points-to analysis but I guess it would be an ABI change.
