https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org,
| |amacleod at redhat dot com,
| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org,
| |jwakely.gcc at gmail dot com
Summary|std::u8string suboptimal |std::u8string suboptimal
|compared to std::string, |compared to std::string
|triggers warnings |
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Adjusting description, since not only have we disabled the warning in the C++
headers so this no longer warns, but the underlying problem has nothing to do
with warnings.
The char_traits<char8_t> specialization is opaque enough such that we can't
figure out the length:
static _GLIBCXX17_CONSTEXPR size_t
length(const char_type* __s)
{
#if __cplusplus >= 201703L
if (std::__is_constant_evaluated())
return __gnu_cxx::char_traits<char_type>::length(__s);
#endif
size_t __i = 0;
while (!eq(__s[__i], char_type()))
++__i;
return __i;
}
OTOH, the <char> specialization falls back to a __builtin_strlen which which is
trivial to see through.
I think this boils down to pinski's comment that we fail to see a string length
calculation in the following sequence, which survives all the way to the
.optimized dump:
<bb 3> [local count: 8687547538]:
# __i_46 = PHI <__i_22(3), 0(2)>
__i_22 = __i_46 + 1;
_24 = MEM[(const char_type &)"123456789" + __i_22 * 1];
if (_24 != 0)
goto <bb 3>; [89.00%]
else
goto <bb 4>; [11.00%]
I've seen variations of the above being turned into __builtin_strlen by fre,
ldist, as well as the strlen [ass. Who's job is it perform this optimization?
