https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #11)
> (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.
The __constant_string_p implementation (__builtin_constant_p in a loop).
> 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?
The first DOM pass evaluates it already but that's too late.
So C++ is basically lacking a feature to give two implementations, one
suitable for constexpr evaluation and one for non-constexpr contexts.
If we could overload on 'constexpr' then we could do
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);
}
staic size_t
length(const char_type* __s)
{
return __builtin_strlen(__s);
}
I can very well imagine that people want to dispatch to fancy library
routines in non-constexpr context while provide the compiler with a
straight-forward constexpr implementation.
Maybe it's easier to retro-fit sth like that into the compiler?
if (__constexpr_evaluation_p)
{
fancy
}
else
return __builtin_strlen (..)
