[Bug libstdc++/112440] New: Compiler does not grok basic_string::resize and basic_string::reserve if _CharT is char

[Bug libstdc++/112440] New: Compiler does not grok basic_string::resize and basic_string::reserve if _CharT is char

[antoshkka at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440

            Bug ID: 112440
           Summary: Compiler does not grok basic_string::resize and
                    basic_string::reserve if _CharT is char
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

#include <string>
void test1(std::size_t summ) {
    std::string result;
    result.resize(summ);

    if (result.size() > summ) {
        __builtin_abort();
    }
}

The resulting assembly contains `call abort` and code to check the string size:
https://godbolt.org/z/zcj3Pc3G8

Looks like this is due to char* aliasing with string internals, switching to
std::u8string removes the `call abort` related assembly:
https://godbolt.org/z/a6bKaqqn5

I've failed to come up with a generic solution, but looks like adding
__builtin_unreachable() to the end of basic_string::resize and
basic_string::reserve helps: https://godbolt.org/z/vWcjqGK94


P.S.: such hints help to shorten the assembly for reserve+append*n cases
https://godbolt.org/z/nsEGsWdP3 , https://godbolt.org/z/qMf4b7dd8 ,
https://godbolt.org/z/1r6dd6d5M which are quire common

[Bug libstdc++/112440] Compiler does not grok basic_string::resize and basic_string::reserve if _CharT is char

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-11-08
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Antony Polukhin from comment #0)
> Consider the example:
> 
> #include <string>
> void test1(std::size_t summ) {
>     std::string result;
>     result.resize(summ);
> 
>     if (result.size() > summ) {
>         __builtin_abort();
>     }
> }
> 
> The resulting assembly contains `call abort` and code to check the string
> size: https://godbolt.org/z/zcj3Pc3G8
> 
> Looks like this is due to char* aliasing with string internals, switching to
> std::u8string removes the `call abort` related assembly:
> https://godbolt.org/z/a6bKaqqn5

Yes, the problem of std::string's data member aliasing itself has been
discussed in bugzilla before. It's presumably also an issue for
std::vector<char>.

I think we discussed a new attribute which would say that none of the members
of *this refer to *this, but that wouldn't be correct for the SSO std::string,
where it's data pointer can point to its internal buffer. Maybe it would work
if it meant that the pointer doesn't alias anything of a different type in
*this. That would allow the char* std::string::_M_dataplus._M_p to point to the
char array std::string::_M_local_buf, but would tell the compiler it never
points to _M_string_length or _M_allocated_capacity.


> I've failed to come up with a generic solution, but looks like adding
> __builtin_unreachable() to the end of basic_string::resize and
> basic_string::reserve helps: https://godbolt.org/z/vWcjqGK94
> 
> 
> P.S.: such hints help to shorten the assembly for reserve+append*n cases
> https://godbolt.org/z/nsEGsWdP3 , https://godbolt.org/z/qMf4b7dd8 ,
> https://godbolt.org/z/1r6dd6d5M which are quire common

That seems worth doing, thanks for the suggestion.

[Bug libstdc++/112440] Compiler does not grok basic_string::resize and basic_string::reserve if _CharT is char

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93971

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
See PR 103534 comment 8 which refers to PR 93971

PR 98465 also discusses the problem.