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.
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
