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 9E5D73858C52; Tue,  8 Nov 2022 21:10:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E5D73858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1667941821;
	bh=/pVtEMqbwOC1kq0RNs7Rqjvf/uEN7/oujmMR9dCEgSQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=AuIrZH7K8oPsFZZU5igdKceDVQUNtQCOr5ylss5bOR36KSt/cPxCDsUyJCbtZ6eyv
	 0Q+RMUN6YFKWA0hjtee4+F871edJihDYFws2nIPoqOYlRso2T9X+FUzxtTO3qn7c1H
	 XV4Erw9CnDjezFlTWjion/7RbG1VHfz2uQldkwGg=
From: "dimitri at ouroboros dot rocks" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/107582] - -Wanalyzer-use-of-uninitialized-value false
 positive using pthread_cond_timedwait
Date: Tue, 08 Nov 2022 21:10:20 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dimitri at ouroboros dot rocks
X-Bugzilla-Status: UNCONFIRMED
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-107582-4-g3AWDzsZZ9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107582-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107582-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=3D107582

--- Comment #2 from dimitri at ouroboros dot rocks ---
I've run into a weird false positive for the analyzer that seems to only oc=
cur
with pthread_cond_timedwait.

Compile the test file using

gcc -c -fanalyzer test_if_else_pthread.c

This will work fine.

But if the while loop is enabled (which should be there in correct code):

gcc -c -fanalyzer test_if_else_pthread_fp.c

the following false-positive occurs:


    |   38 |         while (z =3D=3D 0 && ret !=3D ETIMEDOUT)
    |      |                       ^
    |      |                       |
    |      |                       (4) following =E2=80=98true=E2=80=99 bra=
nch...
    |   39 | #endif
    |   40 |                 ret =3D pthread_cond_timedwait(&cond, &mutex, =
&now);
    |      |                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~
    |      |                       |
    |      |                       (5) ...to here
    |   41 |=20
    |   42 |         if (ret !=3D ETIMEDOUT)
    |      |            ~=20=20=20=20=20=20=20=20=20=20=20
    |      |            |
    |      |            (6) following =E2=80=98false=E2=80=99 branch (when =
=E2=80=98ret =3D=3D 110=E2=80=99)...
    |
  =E2=80=98main=E2=80=99: event 7
    |
    |   45 |         pthread_cleanup_pop(1);
    |      |         ^~~~~~~~~~~~~~~~~~~
    |      |         |
    |      |         (7) ...to here
    |
  =E2=80=98main=E2=80=99: events 8-10
    |
    |   47 |         if (ret =3D=3D ETIMEDOUT)
    |      |            ^
    |      |            |
    |      |            (8) following =E2=80=98false=E2=80=99 branch (when =
=E2=80=98ret !=3D 110=E2=80=99)...
    |......
    |   50 |         printf("x =3D %d\n", *x);
    |      |         ~~~~~~~~~~~~~~~~~~~~~~
    |      |         |
    |      |         (9) ...to here
    |      |         (10) use of uninitialized value =E2=80=98x=E2=80=99 he=
re

Obviously, ret =3D=3D ETIMEDOUT and ret !=3D ETIMEDOUT can't both be false.

I've tried writing a smaller example using mock functions that randomly ret=
urn
ETIMEDOUT instead of pthread_cond_timeout and that did not reproduce the fa=
lse
positive.=