https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> So I've analyzed it more and it is because
>
> static _GLIBCXX17_CONSTEXPR size_t
> length(const char_type* __s)
> {
> #if __cplusplus >= 201703L
> if (__constant_string_p(__s))
> return __gnu_cxx::char_traits<char_type>::length(__s);
> #endif
> return __builtin_strlen(__s);
> }
>
> confuses us because of the stupid structure of __constant_string_p.
>
> Is this some odd requirement of O(1) length for constant strings? Why not
> make it constexpr evaluated instead? Didn't we invent some special
> __builtin_constant_p for this? __constexpr_p ()? Quoting
> __constant_string_p:
>
> template<typename _CharT>
> static _GLIBCXX_ALWAYS_INLINE constexpr bool
> __constant_string_p(const _CharT* __s)
> {
> while (__builtin_constant_p(*__s) && *__s)
> __s++;
> return __builtin_constant_p(*__s);
> }
I think it is a poor man's workaround for the constexpr evaluation, until the
FE can handle the memory/string builtins in constexpr evaluation.
We need some helper routines for constexpr reading and storing a character to a
certain pointer, and then basically open-code the needed builtins using those
two helpers.
Is the problem __constant_string_p implementation or the
__gnu_cxx::char_traits<char_type>::length(__s); part? If only
__constant_string_p, then it might be enough to handle constexpr evaluation of
__builtin_strlen.
Is the problem that when optimizing we defer the __builtin_constant_p
evaluation until fab? Perhaps my
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00355.html patch would help here
instead?
