On Tue, 17 Mar 2026 at 20:44, Patrick Palka <[email protected]> wrote:
>
> On Tue, 17 Mar 2026, Jason Merrill wrote:
>
> > On 3/17/26 2:09 PM, Jakub Jelinek wrote:
> > > On Tue, Mar 17, 2026 at 05:11:42PM +0100, Jakub Jelinek wrote:
> > > > The following patch adds a plugin (sorry, to check-g++ testsuite rather
> > > > than libstdc++ testsuite because in plugin.exp we have all the needed
> > > > infrastructure.
> > >
> > > Here is a new version of the patch. It now adds automatic whitelisting
> > > (basically, any identifier (except for namespace identifiers, sorry) it
> > > sees
> > > inside
> > > of std namespace and nested namespaces in it (excluding non-inline
> > > namespaces with _ prefixed names) during the namespace and class and
> > > also enumerators walk are whitelisted, and non-uglified name diagnostics
> > > is deferred until end of TU at which point were report the non-whitelisted
> > > ones one way and whitelisted ones another way which doesn't fail the
> > > testcase). And it does diagnose badnames and non-uglified names of
> > > functions/classes etc. even in the implementation non-inline namespaces
> > > like std::__gnu_cxx etc.
> > >
> > > With the patch Jonathan posted, the results are (if you see something that
> > > looks like a bug in the plugin, please let me know including details why
> > > and
> > > I'll try to fix it):
> > > libstdc++-v3/include/bits/atomic_base.h:1137:7: note: non-uglified name
> > > 'is_lock_free'
> > > libstdc++-v3/include/bits/atomic_base.h:1145:7: note: non-uglified name
> > > 'store'
> > > libstdc++-v3/include/bits/atomic_base.h:1152:7: note: non-uglified name
> > > 'load'
> > > libstdc++-v3/include/bits/atomic_base.h:1173:7: note: non-uglified name
> > > 'compare_exchange_weak'
> > > libstdc++-v3/include/bits/atomic_base.h:1183:7: note: non-uglified name
> > > 'compare_exchange_strong'
> > > libstdc++-v3/include/bits/atomic_base.h:1220:7: note: non-uglified name
> > > 'fetch_add'
> > > libstdc++-v3/include/bits/atomic_base.h:1225:7: note: non-uglified name
> > > 'fetch_sub'
> > > libstdc++-v3/include/bits/atomic_base.h:1230:7: note: non-uglified name
> > > 'fetch_and'
> > > libstdc++-v3/include/bits/atomic_base.h:1235:7: note: non-uglified name
> > > 'fetch_or'
> > > libstdc++-v3/include/bits/atomic_base.h:1240:7: note: non-uglified name
> > > 'fetch_xor'
> >
> > I don't think we need to gratuitously change the names of existing
> > functions.
> > Especially when the names are shared with standard APIs, so should be safe
> > from macros.
>
> FWIW I think we do need to rename non-uglified member functions still
> since they can cause name lookup ambiguities, e.g. if std::vector for
> some reason defines a fetch_xor then it'd break
>
> struct A { void fetch_xor(); };
> struct B : A, std::vector<int> { };
> void f(B& b) { b.fetch_xor(); };
But that's not the case here.
We have
namespace std::__atomic_impl {
template<...> T store(...);
}}
which is called by std::atomic_ref<T>::store.
I don't think there's a problem.
