On Wed, Feb 11, 2026 at 7:14 AM François Dumont <[email protected]> wrote:
> > On 2/9/26 09:48, Tomasz Kaminski wrote: > > > > On Thu, Feb 5, 2026 at 7:17 AM 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 this patch is turning what would previously well-known performance > impact into impact on the compilation, both the time and the memory > consumption > at compile time. cosntexpr interpreters are currently an order of > magnitude slower than runtime > computation, and multiplying it may lead to simply being unable to produce > binary. > > This may lead to _GLIBCXX_DEBUG being unusable for programs with heavy > use of vector at compile time (I am seeing reflection as driver for it, > but this could happen > already), to find a bug that occurs at runtime. > > I wish I could test my patch on such program. Any idea on how this could > be done ? > I would start with this example from format: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r13.html#a-universal-formatter (It already works with reflection on GCC-16: https://godbolt.org/z/evfqPznz8 ) And then do some stress testing on it, by having a struct that looks like: template<int N> struct Big { int mem1; std::string mem2; /* ..... */ int mem50; (many members) }; template<int N> struct formatter<Big<N>> : universal_formatter {}; Then doing: template for (constexpr int v : std::views::iota(1, 1000) std::print({}, Big<V>{....}); And seeing how much time/memory compiling this program takes with/withotu your changes, and post the result here. > Sounds like we would need such benches at compiler level. Isn't there > already such a think in gcc testsuite that I could run ? > > > > >> I don't know much about the reflection subject but _GLIBCXX_DEBUG is >> optional so maybe it won't be usable along with reflection with this >> patch. It doesn't sound like a big deal to me but if it is then I'm >> ready to cut again all debug check when in consteval mode or when >> reflection is activated. > > In the context of this patch, only relevant information about reflection, > is that > it will lead to heavy usage of std::vector of scalar types, at compile > time. Not > only creating such vectors, but also transforming them using standard > algorithms. > > What would mitigate my concerns here, is measurements of compile time > impact > of this case, on such examples. > > I've no idea how to provide meaningful figures. Have such figures been > collected when _GLIBCXX_DEBUG has been adapted to constexpr ? I could then > compare to same figures with my patch. > > This patch is also a nice performance enhancement to _GLIBCXX_DEBUG mode > at runtime as some basic checks are now inline rather than done through a > library symbol (_M_singular and _M_can_compare). > > So I'm reworking it to limit its potential impact on compilation > resources. Maybe a _GLIBCXX_CONSTEVAL_DEBUG mode could be a solution to > evaluate it in the future. > > François >
