https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2023-12-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #0)
> I know this is not a supported scenario, but I'm wondering if it's still
> easy to support.
>
> We have some libraries that use C++ mostly as an abstraction layer and try
> to ensure that it needs no runtime support from libstdc++.
>
> A recent commit: g:5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781 changed how
> `__glibcxx_assert` is defined and now always calls
> `std::__glibcxx_assert_fail`.
>
> This means that now you always need libstdc++ even in contex where things
> would have been folded away before. Similarly we're getting the same thing
> through usage of `std::unique_ptr`.
Ugh, that's undesirable. It should only depend on that symbol when
_GLIBCXX_ASSERTIONS is defined, but the change means we also use that symbol
for constexpr checks.
I'm surprised it doesn't get folded away though, since the code looks like:
if (std::__is_constant_evaluated())
if (__builtin_expect(COND, false))
__glibcxx_assert_fail(...);
Since __is_constant_evaluated is always false at runtime, that function can
never be called. Either it's needed during compile-time and makes the program
ill-formed, or it's not needed at all.
Ah, __is_constant_evaluated() is not marked always_inline, so at -O0 it just
looks like a normal function call.
> It seems that undefining `_GLIBCXX_VERBOSE_ASSERT` gets it to go to
> `__builtin_abort()` which makes it work again.
>
> If this change was intentional, would it be possible to make
> `_GLIBCXX_VERBOSE_ASSERT` user configurable?
You can use --disable-libstdcxx-verbose for that, or do you need to control it
during preprocessing?
