On Thu, 20 Nov 2025, 20:36 François Dumont, <[email protected]> wrote:
> > On 11/19/25 14:51, Jonathan Wakely wrote: > > On Tue, 18 Nov 2025 at 21:38, François Dumont<[email protected]> > wrote: > >> Ok, here is the new patch, only fixing thestd::erase_if behavior for > >> the _GLIBCXX_DEBUG. > > Is that right? I thought this change is to benefit direct uses of > > __gnu_debug::vector notstd::vector with _GLIBCXX_DEBUG? The first new > > test already passes when usingstd::vector with -D_GLIBCXX_DEBUG. In > > fact, it FAILs with this patch! So this change is not helping > > _GLIBCXX_DEBUG, it's making it worse. > > > > I see the problem there, you need to check __glibcxx_erase_if in > > <debug/vector>, not __cpp_lib_erase_if. The latter hasn't been defined > > yet because <debug/vector> gets included before > > __glibcxx_want_erase_if is defined in <vector>. You probably won't see > > the FAILs for a default configuration of GCC, but if you configure > > with --disable-libstdcxx-pch then it will fail. > > Caught again by pch, I wonder if those should not be disabled per > default when running tests. > They speed up the tests, that's the main benefit of pch. > I did this for the 2 new tests. > > > Also, what is the commit message for this patch? > > The original commit message from > > https://gcc.gnu.org/pipermail/gcc-patches/2025-November/701007.html no > > longer applies, because this is a different patch (there's no clean up > > being done ... maybe everything else in the original still applies?) > > Yes, I kept same message, it was not talking about modification of > std::erase_if implementation as I replicate the implementation I had put > in place for __gnu_debug::inplace_vector instead of replicating the one > for std::vector. At least now there is a test to detect this wrong change. > > > > OK for trunk with both uses of __cpp_lib_erase_if in <debug/vector> > > fixed, and an updated commit message. > > > Attached patch committed.
