On 2/5/26 15:41, Jonathan Wakely wrote:
On Thu, 5 Feb 2026 at 06:17, François Dumont <[email protected]> wrote:
On 1/27/26 11:31, Jonathan Wakely wrote:
On Tue, 27 Jan 2026 at 08:30, Tomasz Kaminski <[email protected]> wrote:
On Mon, Jan 26, 2026 at 10:25 PM François Dumont <[email protected]> wrote:
Hi
libstdc++: [_GLIBCXX_DEBUG] Make constant evaluation compatible
In a constant evaluation context the _GLIBCXX_DEBUG is working in a
degradated mode where only iterators are keeping a link to their
container,
the container won't have a list of its iterators.
In std::__debug::vector and std::__debug::inplace_vector remove all
calls to
std::is_constant_evaluated and code associated to it when returning
true. The
same code is now used in both contexts.
What are the exact benefits of this change? During constant evaluation we
already
detect all UB caused by access via invalid or past the end pointers, so most of
the
cases are detected.
As this will have non-trivial impact on compile-times of programs operation on
vector at compile time (including c++26) reflection, I would like to see a more
concrete
cost (how much longer a decently size example using reflection compilers) vs
benefits
(examples of situations where this new implementation will detect breach of
library preconditions,
that are not already detected).
In this new version I've added an example of breach.
_GLIBCXX_DEBUG mode is already known to be costly and is documented as
having a performance impact. It seems normal to me that it also has some
impact in consteval context.
But usually the extra overhead is useful for finding bugs, but if the
bugs are already found during consteval, then it just slows down
compilation without finding any more problems.
When testing the new consteval_erase_neg.cc wo _GLIBCXX_DEBUG mode it gives:
Excess errors:
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator.h:1352:
error: '((((const int*)(& heap )) - ((const int*)(& heap ))) <unknown
operator> 4)' is not a constant expression
With _GLIBCXX_DEBUG mode:
/home/fdumont/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/debug/consteval_erase_neg.cc:20:
error: non-constant condition for static assertion
In file included from
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/debug.h:90,
from
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:68,
from
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/algorithm:62,
from
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h:51,
from <command-line>:
/home/fdumont/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/debug/consteval_erase_neg.cc:20:
in 'constexpr' expansion of 'test01()'
/home/fdumont/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/debug/consteval_erase_neg.cc:16:
in 'constexpr' expansion of
'v1.std::__debug::vector<int>::erase(__gnu_debug::_Safe_i
terator<__gnu_cxx::__normal_iterator<const int*,
std::__cxx1998::vector<int, std::allocator<int> > >,
std::__debug::vector<int>,
std::random_access_iterator_tag>(v2.std::__debug::vector<int>
::begin()))'
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/macros.h:54:
error: call to non-'constexpr' function 'void __gnu_debug::__glibcxx_fail()'
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/macros.h:65:
note: in expansion of macro '_GLIBCXX_DEBUG_VERIFY_AT_F'
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/macros.h:226:
note: in expansion of macro '_GLIBCXX_DEBUG_VERIFY'
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:752:
note: in expansion of macro '__glibcxx_check_erase'
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/macros.h:45:
note: 'void __gnu_debug::__glibcxx_fail()' declared here
compiler exited with status 1
So spotting the culprit line.
So _GLIBCXX_DEBUG mode is somehow to consteval what libbacktrace is to
runtime case :-).
I still find it useful but you're the bosses here, let me know your
decision.
François
