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 288133858CDB; Thu,  2 Mar 2023 21:25:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 288133858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677792345;
	bh=nx/ojia4O8y0clbfJlDsKk6IHE9qF6+blqhEpP+vppU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Ic3NCt1apKnBBAS99dBSnTp5GFkJoFA4Btt2KyXxaER7BMMLvq494RGAmOirodYfM
	 4xEjsoj8KwVbwJfgxmC/voWxjrGELwwWj2lEIlJcY2EHi+MEPap6+M/RIOprDz6PJ5
	 C/2i0HZHRI1pBUfjyzYQy2qRfwRscz1UihcesVyw=
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:25:45 +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-ZQQYVb2WMl@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 #11 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> 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.)

Probably not (without further patching of the analyzer, at least).

For functions it can't see the definition of, the analyzer will respect con=
st
annotations and treat such a function as always returning the same results =
when
given the same set of arguments.

However, I don't think it will respect a const annotation on an function it=
 can
see the definition of; I think in your case it will simply try to (badly)
simulate the insides of get_cpu_info.   To what extent that's going to lead=
 to
false positives is hard to say.=