[Bug middle-end/94189] [9 Regression] -fcompare-debug failure on Wstringop-overflow-22.c since r9-3242

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:65de83595faeccd83bc0fefbfb79768f8a3bb2b6

commit r9-8398-g65de83595faeccd83bc0fefbfb79768f8a3bb2b6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 17 10:42:35 2020 +0100

    expand: Don't depend on warning flags in code generation of strnlen
[PR94189]

    The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't
    that we'd emit different code based on -g or non-debug, but rather that
    we emit different code depending on whether -w is used or not (or e.g.
    -Wno-stringop-overflow or whether some other pass emitted some other
warning
    already on the call).

    Code generation shouldn't depend on whether we emit a warning or not if at
    all possible.

    The following patch punts (i.e. doesn't optimize the strnlen call to a
    constant value) if we would emit the warning if it was enabled.
    In the PR there is an alternate patch which does optimize the strnlen call
    no matter if we emit the warning or not, though I think I prefer the
version
    below, e.g. the strnlen call might be crossing field boundaries, which is
in
    strict reading undefined, but I'd be afraid people do that in the real
    world programs.

    2020-03-17  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/94189
            * builtins.c (expand_builtin_strnlen): Do return NULL_RTX if we
would
            emit a warning if it was enabled and don't depend on
TREE_NO_WARNING
            for code-generation.

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