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 20A343858CDB; Thu,  2 Mar 2023 21:29:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20A343858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677792546;
	bh=VzK0bYYw6+uPMDnsniSriKinbASqJ3D9vybx0j/S4z0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=UqneLXWoXLEbz8NgXJIn962NNFa7C8N4jFN97wrZF1+OGJSotK077ptwooOWTU+bp
	 ZOQdsJ2H1gOqIAwJ8qvThVlaTBjhwuPoyvDriD3d9etuPpLx0fVu31t8gN1JD59wN9
	 7ICSziWPBcy+F7jdyqnfzj+ArxLC38oZnwvinb+k=
From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
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:29:05 +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: dmalcolm at gcc dot gnu.org
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: <bug-108968-4-JRp5coTHnv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108968-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108968-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #12 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> Our code does fundamentally rely on get_cpu_info() always returning the s=
ame
> 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
> when used multiple times.
>=20
> 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
> stacks.

Another issue is that even if the analyzer "knows" that get_cpu_info() alwa=
ys
returns the same value, it doesn't know what memory is being pointed to, an=
d so
has to assume that in:

   T old_value =3D get_cpu_info()->current;

   some_function_call ();

   T new_value =3D get_cpu_info()->current;

that old_value doesn't necessarily equal new_value, since some_function_cal=
l ()
could have modified the value of "current".=