From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 671AB3858D38; Sun, 28 May 2023 22:16:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 671AB3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685312166; bh=4/661YhKKIdFMbkwczDjdbRM6mACzjjJOxqfAg81Ih4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=H8a53FnhpNlCML3famNG8l0sZ3WaICEvSjmzO6acsGwu7vmpagHIY/xuF9mY4f0SA K3LT7o0Z0sKb+jkNTDi7rMtAm4NKBUuAHqF3y3viIyMRlv7AIz0unuB6aSyGEGbtvm UyomRGx8oSR2BIKHEz7Xe0jHo9Vg24Jl2QYJhkys= From: "bruno at clisp dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions Date: Sun, 28 May 2023 22:16:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 13.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: bruno at clisp dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109914 --- Comment #3 from Bruno Haible --- (In reply to Jan Hubicka from comment #2) > The reason why gcc warns is that it is unable to prove that the function = is > always finite. This means that it can not auto-detect pure attribute since > optimizing the call out may turn infinite program to finite one.=20 > So adding the attribute would still help compiler to know that the loops = are > indeed finite. Thanks for explaining. So, the warning asks the developer not only to add an __attribute__((__pure__)) marker, but also to verify that the function terminates. In this case, it does, but it took me a minute of reflection to convince myself. For what purpose shall the developer make this effort? The documentation https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Common-Function-Attributes.ht= ml says that it's to allow the compiler to do common subexpression elimination. But in this case, the compiler could easily find out that it cannot do comm= on subexpression elimination anyway, because: - The only caller of this function (have_xattr) is file_has_acl. - In this function, there are three calls to have_xattr. - Each of them is executed only at most once. Control flow analysis shows this. - Each of them has different argument lists: The first argument is a stri= ng literal in each case, namely "system.nfs4_acl", "system.posix_acl_access", "system.posix_acl_default" respectively. So, there is no possibility for common subexpression elimination here, even= if the function was marked "pure". Therefore it is pointless to suggest to the developer that it would be a ga= in to mark the function as "pure" and that it is worth spending brain cycles on that.=