On Thu, 22 May 2025, 08:26 Jonathan Wakely, <jwakely....@gmail.com> wrote:
> > > On Thu, 15 May 2025, 06:26 François Dumont, <frs.dum...@gmail.com> wrote: > >> Got >> >> On 14/05/2025 18:46, Jonathan Wakely wrote: >> > On Wed, 14 May 2025 at 17:31, François Dumont <frs.dum...@gmail.com> >> wrote: >> >> On 12/05/2025 23:03, Jonathan Wakely wrote: >> >>> On 31/03/25 22:20 +0200, François Dumont wrote: >> >>>> Hi >> >>>> >> >>>> Following this previous patch >> >>>> https://gcc.gnu.org/pipermail/libstdc++/2024-August/059418.html I've >> >>>> completed it for the _Safe_unordered_container_base type and >> >>>> implemented the rest of the change to store the safe iterator >> >>>> sequence as a pointer-to-const. >> >>>> >> >>>> libstdc++: Make debug iterator pointer sequence const [PR116369] >> >>>> >> >>>> In revision a35dd276cbf6236e08bcf6e56e62c2be41cf6e3c the debug >> >>>> sequence >> >>>> have been made mutable to allow attach iterators to const >> >>>> containers. >> >>>> This change completes this fix by also declaring debug unordered >> >>>> container >> >>>> members mutable. >> >>>> >> >>>> Additionally the debug iterator sequence is now a >> >>>> pointer-to-const and so >> >>>> _Safe_sequence_base _M_attach and all other methods are const >> >>>> qualified. >> >>>> Symbols export are maintained thanks to __asm directives. >> >>>> >> >>> I can't compile this, it seems to be missing changes to >> >>> safe_local_iterator.tcc: >> >>> >> >>> In file included from >> >>> >> /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.h:444, >> >>> from >> >>> /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:33: >> >>> >> /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc: >> >>> In member function ‘typename >> >>> __gnu_debug::_Distance_traits<_Iterator>::__type >> >>> __gnu_debug::_Safe_local_iterator<_Iterator, >> >>> _Sequence>::_M_get_distance_to(const >> >>> __gnu_debug::_Safe_local_iterator<_Iterator, _Sequence>&) const’: >> >>> >> /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:47:17: >> >>> error: there are no arguments to ‘_M_get_sequence’ that depend on a >> >>> template parameter, so a declaration of ‘_M_get_sequence’ must be >> >>> available [-Wtemplate-body] >> >>> 47 | _M_get_sequence()->bucket_size(bucket()), >> >>> | ^~~~~~~~~~~~~~~ >> >>> >> /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:47:17: >> >>> note: (if you use ‘-fpermissive’, G++ will accept your code, but >> >>> allowing the use of an undeclared name is deprecated) >> >>> >> /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:59:18: >> >>> error: there are no arguments to ‘_M_get_sequence’ that depend on a >> >>> template parameter, so a declaration of ‘_M_get_sequence’ must be >> >>> available [-Wtemplate-body] >> >>> 59 | -_M_get_sequence()->bucket_size(bucket()), >> >>> | ^~~~~~~~~~~~~~~ >> >>> >> >> Yes, sorry, I had already spotted this problem, but only updated the PR >> >> and not re-sending patch here. >> >> >> >> >> >>>> Also available as a PR >> >>>> >> >>>> https://forge.sourceware.org/gcc/gcc-TEST/pulls/47 >> >>>> >> >>>> /** Detach all singular iterators. >> >>>> * @post for all iterators i attached to this sequence, >> >>>> * i->_M_version == _M_version. >> >>>> */ >> >>>> void >> >>>> - _M_detach_singular(); >> >>>> + _M_detach_singular() const >> >>>> + >> __asm("_ZN11__gnu_debug19_Safe_sequence_base18_M_detach_singularEv"); >> >>> Does this work on all targets? >> >> No idea ! I thought the symbol name used here just had to match the >> >> entries in config/abi/pre/gnu.ver. >> > That linker script is not used for all targets. >> >> Ok, got it, I only need to use this when symbol versioning is activated. >> > > I don't think that's right. For targets that don't use gnu.ver we still > want to preserve the same symbols. They just aren't versioned on those > targets. > And e.g. Solaris uses versioning, but a different format, not gnu.ver, and > I don't remember it the same macro is defined. > > Isn't it possible to do this without asm somehow? At least as a fallback > for targets that don't use gnu.ver > Basically this needs more research, and then testing on other targets. > > >> I think this new patch should do it if so. >> >> François >> >>
