From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C87113858C83; Thu, 2 Mar 2023 21:15:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C87113858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677791756; bh=gC8ISFdjfS8H90W4UF9F/PUB7R44Oe4mPH4I3YjI044=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bBQbOo7jWdGetlTYbKa+3aq1TPxX+lYNdk41Vk/0Diggu5h+JYvqtsYQeBl6HtkP0 8NXDHKEzGCKDAreEzYPg7yG3Ni/zzIgO9NBQr38XEDScg3BnloI92aZPyllFKtPw0K uCa0uxmdBc+EYsA6Aea16293IUqC8NPVvJzgms4A= From: "andrew.cooper3 at citrix dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer Date: Thu, 02 Mar 2023 21:15:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: analyzer X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andrew.cooper3 at citrix dot com X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dmalcolm 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=3D108968 --- Comment #9 from Andrew Cooper --- Thank-you for the fix. I've recompiled master and this uninitialised warning has gone. Unfortunately, Xen isn't GCC-13 clean (seems like a real bug in Xen), and t= he analyser has pointed out various other things which I'm still looking in to= . I don't see anything which looks like it is a new knock-on effect from this change. Our code does fundamentally rely on get_cpu_info() always returning the same pointer (on a single CPU). For example, `current` is defined as `get_cpu_info()->current` and we do expect that to yield the same pointer w= hen used multiple times. Even if the analyser was interpreting the generated asm, there's no way it could prove this without knowing the size/alignment constraints of our stac= ks. Would a const annotation on get_cpu_info() be likely to help? It occurs to= me that this is true in all cases that the compiler could legitimately reason about. (It would only cease being true if we fell off our stack, at which point UB is the very least of our worries.)=