On Wed, Feb 11, 2026 at 7:31 PM François Dumont <[email protected]> wrote:
> > On 2/11/26 14:06, Tomasz Kaminski wrote: > > > > 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) > > Thanks, I'll give it a try. > > 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; > > Note that this patch have no compilation performance impact on std::string > . > Ah, I forgot to comment. My point was not to see impact on std::string, I just wanted to suggest that these members should have different types that are still formattable. > Unlike other containers the _GLIBCXX_DEBUG mode is not automatically > substituting std::string with its __gnu_debug::string counterpart due to > abi issues. > > So the only impact on std::string with this patch could have been on > calls to basic_string<>::replace<_IntputIte> members that are calling > __glibcxx_require_valid_range macro. But this patch is not touching to what > is done behind this macro. > > > /* ..... */ > > 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 >> >
