Turns out that 23_containers/vector/erasure.cc was showing the problem
in _GLIBCXX_DEBUG mode.
I had only run 25_algorithms tests in _GLIBCXX_DEBUG mode.
This is what I'm testing, I 'll let you know tomorrow morning if all
successful.
Of course feel free to do or ask for a revert instead.
François
On 19/02/2024 09:21, Jonathan Wakely wrote:
On Mon, 19 Feb 2024, 08:12 Jonathan Wakely, <jwakely....@gmail.com> wrote:
On Mon, 19 Feb 2024, 07:08 Stephan Bergmann, <sberg....@gmail.com>
wrote:
On 2/17/24 15:14, François Dumont wrote:
> Thanks for the link, tested and committed.
I assume this is the cause for the below failure now,
Yes, the new >= C++11 overload of __niter_base recursively unwraps
multiple layers of wrapping, so that a safe iterator wrapping a
normal iterator wrapping a pointer is unwrapped to just a pointer.
But then __niter_wrap doesn't restore both layers.
Actually that's not the problem. __niter_wrap would restore both
layers, except that it uses __niter_base itself:
> 347 | { return __from + (__res - std::__niter_base(__from)); }
> | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
And it seems to be getting called with the wrong types. Maybe that's
just a bug in std:: erase or maybe niter_wrap needs adjusting.
I'll check in a couple of hours if François doesn't get to it first.
I have to wonder how this wasn't caught by existing tests though.
diff --git a/libstdc++-v3/include/bits/stl_algobase.h
b/libstdc++-v3/include/bits/stl_algobase.h
index 0f73da13172..d534e02871f 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -344,7 +344,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_GLIBCXX20_CONSTEXPR
inline _From
__niter_wrap(_From __from, _To __res)
- { return __from + (__res - std::__niter_base(__from)); }
+ { return __from + (std::__niter_base(__res) - std::__niter_base(__from)); }
// No need to wrap, iterator already has the right type.
template<typename _Iterator>
