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 > I think this new patch should do it if so. > > François > >
