[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:fc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7

commit r14-10231-gfc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 22 09:13:50 2024 +0200

    strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

    The following testcase is miscompiled because
    strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
    the !si->full_string_p case.
    If si->full_string_p, it correctly computes minlen and maxlen as
    minimum and maximum length of the '\0' terminated stgring and
    clears *nulterm (ie. makes sure !full_string_p in the ultimate
    caller) if minlen is equal or larger than nbytes and so
    '\0' isn't guaranteed to be among those bytes.
    But in the !si->full_string_p case, all we know is that there
    are [minlen,maxlen] non-zero bytes followed by unknown bytes,
    so effectively the maxlen is infinite (but caller cares about only
    the first nbytes bytes) and furthermore, we never know if there is
    any '\0' char among those, so *nulterm needs to be always cleared.

    2024-05-22  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/115152
            * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
            !si->full_string_p, clear *nulterm and set maxlen to nbytes.

            * gcc.dg/pr115152.c: New test.

    (cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)