On Mon, 16 Mar 2026 at 13:46, Patrick Palka <[email protected]> wrote: > > On Sat, 14 Mar 2026, François Dumont wrote: > > > Patch extracted from this PR: > > > > https://forge.sourceware.org/gcc/gcc-TEST/pulls/136 > > > > I was able to reproduce the bug in the context the same PR on those tests: > > > > 23_containers/vector/bool/capacity/constexpr.cc > > 23_containers/vector/bool/modifiers/constexpr.cc > > 23_containers/vector/modifiers/constexpr.cc > > > > It was the reason of doing this change in the PR. > > > > libstdc++: [_GLIBCXX_DEBUG] _M_invalidate_if incompatible with C++20 > > [PR124444] > > > > __gnu_cxx::__scoped_lock cannot be instantiated in a C++20 constexpr > > function. > > > > libstdc++-v3/ChangeLog: > > > > * include/debug/safe_sequence.h > > (_Safe_sequence::_M_invalidate_if_impl): New. > > (_Safe_sequence::_M_invalidate_if): Call later if not > > __is_constant_evaluated. > > * include/debug/safe_sequence.tcc: Rename _M_invalidate_if into > > _M_invalidate_if_impl and remove C++20 constexpr. > > > > Tested under Linux x86_64 _GLIBCXX_DEBUG mode. > > > > Ok to commit ? > > > > François > > > > Can also use the _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN/END > macros from debug/safe_iterator.h to work around this constexpr > restriction (since r14-8252-g3d3145e9e1461e). But I think I prefer > your approach in this case anyway.
I completely forgot about this - thanks for the reminder.
