From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id F123F3945C18; Tue, 17 Mar 2020 18:57:56 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F123F3945C18
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1584471476;
 bh=nTavRnTHIcr69xiN2oLF63gibgfK+ZZxDQ9hKyLpa+k=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=u++yf5BC9BetImmrINVFma8+q02hYHa/t+EDqqhKEFWKmfahrRp26tOMsshxH4dfz
 2bvwnVdf7zDA19Y6RAloJAnhPNfFrCpTaBwBcyNk1LKHCx6liwjLNhIMq5ad6Pnwk9
 iOCVjEa8mBmvR7+4FnCQxzXhIlbK/wbP9+thmzpo=
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/94189] [9 Regression] -fcompare-debug failure on
 Wstringop-overflow-22.c since r9-3242
Date: Tue, 17 Mar 2020 18:57:56 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 9.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 9.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-94189-4-yHVx839pJs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94189-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94189-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 18:57:57 -0000

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

--- 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 i=
sn'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 c=
all
    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.=