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