[Bug c/56574] New: False possibly uninitialized variable warning

[Bug c/56574] New: False possibly uninitialized variable warning

[mark.d.rustad at intel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

             Bug #: 56574
           Summary: False possibly uninitialized variable warning
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mark.d.rustad@intel.com


The following code produces the warning,'value' may be used uninitialized:

int get_value(void);

void show_problem(int flag)
{
    int value;

    if (!flag)
        value = get_value();

    for (;;) {
        if (!flag && value)
            continue;

        if (!flag)
            break;
    }
}

The warning occurs only with -O1 and -O2 optimization. -O0 and -O3 and higher
do not. It also occurs with many versions. I have gotten the same result with
the following versions of gcc:

i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)

Interestingly, the much larger function that originally displayed the problem
does not generate a warning with the 4.7.0 compiler, but does on the others.

[Bug c/56574] False possibly uninitialized variable warning

[mark.d.rustad at intel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

--- Comment #1 from Mark Rustad <mark.d.rustad at intel dot com> 2013-03-08 19:24:27 UTC ---
It also appears that incorrect code is generated in cases where the warning is
produced. That incorrect code was referencing the uninitialized value. So the
warning is consistent with the code generated, but the code is wrong.

[Bug middle-end/56574] False possibly uninitialized variable warning

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-08 19:51:05 UTC ---
I don't think it matters if the unitialized value is used in this case as:
  pretmp_14 = flag_3(D) == 0;
  pretmp_1 = value_12 != 0;
  pretmp_15 = pretmp_1 & pretmp_14;

pretmp_14 will always be false (0) so pretmp_15 wil also be false (0)

[Bug middle-end/56574] False possibly uninitialized variable warning

[thiago at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

Thiago Macieira <thiago at kde dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago at kde dot org

--- Comment #3 from Thiago Macieira <thiago at kde dot org> 2013-03-08 21:11:19 UTC ---
Looking at the code that GCC generated (4.7.2 from Fedora and similarly with
pristine 4.8 trunk@196249):

%edi = flag; %eax = value
    11          testl   %edi, %edi
    12          je      .L12
.L12 is the call to get_value() is placed
    13  .L2:
    14          testl   %edi, %edi
    15          sete    %dl
    16          testl   %eax, %eax
Here, EAX might be uninitialised
    17          setne   %al
    18          testb   %dl, %al
    19          jne     .L3
.L3 is an infinite loop
    20          testb   %dl, %dl
    21          jne     .L8
.L8 is the function exit (the loop break)
fall-through is an infinite loop

In other words, the warning is true: the generated code *is* using an
uninitialised variable.

The question is whether that is acceptable.

In order for EAX to be uninitialised, we must not have jumped to .L12. Since
the JE jump on line 12 was not taken, SETE must have set DL to 0 on line 15.
Then we compare AL to DL on line 18: as DL is zero, the result of the
comparison is ZF, whichever the value of AL might be. That means the JNZ jump
on line 19 is not taken.

The code will then proceed to the infinite loop.

Conclusion: it's just a bogus warning. It is correct from the point of view of
the assembly code that was generated, but the uninitialised value is never used
in any decisions.

[Bug middle-end/56574] False possibly uninitialized variable warning

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-08 21:25:47 UTC ---
(In reply to comment #3)
> Looking at the code that GCC generated (4.7.2 from Fedora and similarly with
> pristine 4.8 trunk@196249):



For -O2, the generated code looks though:
    testl    %edi, %edi
    sete    %dl
    testl    %eax, %eax
    setne    %al
    andl    %edx, %eax

Here eax might be uninitialized but that is ok because dl will always be 0 when
it is.

[Bug middle-end/56574] False possibly uninitialized variable warning

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-03-11
     Ever Confirmed|0                           |1

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-11 10:43:45 UTC ---
ISO C99 6.5.13 says that 'value' is not evaluated when !flag is false.  But
clearly we are not considering the "side-effect" of using an uninitialized
variable when deciding to output straight-line code sequences.

Affected are at least gimple SSA if-combine and eventually fold and
gimplification (I didn't check them).

Ok, for this testcase it is fold that ends up producing a TRUTH_AND_EXPR.

For SSA if-combine we should only linearize the code if all inner block
SSA (or memory - ugh) uses in

  if (...)
   {
     <here>
     if (...)
      {
...

have a dominating definition.

[Bug middle-end/56574] False possibly uninitialized variable warning

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-11 10:45:08 UTC ---
Note that the 'wrong-code' bits should not be observable but with runtime
simulation tools.

[Bug middle-end/56574] False possibly uninitialized variable warning

[luto at mit dot edu]

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

Andy Lutomirski <luto at mit dot edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luto at mit dot edu

--- Comment #7 from Andy Lutomirski <luto at mit dot edu> ---
I think this has gotten worse in newer GCC versions.  I'm up to six independent
triggers of this bug in my tree.

[Bug middle-end/56574] False possibly uninitialized variable warning

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> ISO C99 6.5.13 says that 'value' is not evaluated when !flag is false.  But
> clearly we are not considering the "side-effect" of using an uninitialized
> variable when deciding to output straight-line code sequences.

But evaluating an uninitialized variable is not a side-effect, unless accessing
the variable itself has a side-effect, so there is no wrong code here.

> Affected are at least gimple SSA if-combine and eventually fold and
> gimplification (I didn't check them).
> 
> Ok, for this testcase it is fold that ends up producing a TRUTH_AND_EXPR.

This analysis looks bogus to me.

[Bug middle-end/56574] False possibly uninitialized variable warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #8)
> > ISO C99 6.5.13 says that 'value' is not evaluated when !flag is false.  But
> > clearly we are not considering the "side-effect" of using an uninitialized
> > variable when deciding to output straight-line code sequences.
> 
> But evaluating an uninitialized variable is not a side-effect, unless
> accessing the variable itself has a side-effect, so there is no wrong code
> here.

Perhaps the uninit pass can be taught that for a & b when a may be
uninitialized is actually guarded by if(b!=0). I think this will fix the bug
here, no?
>From gcc-bugs-return-453390-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 06 14:12:01 2014
Return-Path: <gcc-bugs-return-453390-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30374 invoked by alias); 6 Jun 2014 14:12:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30354 invoked by uid 48); 6 Jun 2014 14:11:57 -0000
From: "aladjev.andrew at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61428] New: "maybe-uninitialized" is broken in all current versions (4.7-4.10)
Date: Fri, 06 Jun 2014 14:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aladjev.andrew at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-61428-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
X-SW-Source: 2014-06/txt/msg00472.txt.bz2
Content-length: 2034

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

            Bug ID: 61428
           Summary: "maybe-uninitialized" is broken in all current
                    versions (4.7-4.10)
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aladjev.andrew at gmail dot com

Created attachment 32900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32900&action=edit
test.c

Please checkout attached test.c. There are no variables in this file, that may
be uninitialized.

gcc-4.7.3 -Werror -pedantic -Wall -Wextra -std=gnu99 -pthread -pipe -O2 test.c
-o test
>>
test.c: In function ‘func’:
test.c:54:14: error: ‘lock_1’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors

gcc-4.8.2 -Werror -pedantic -Wall -Wextra -std=gnu99 -pthread -pipe -O2 test.c
-o test
>>
test.c: In function ‘func’:
test.c:54:14: error: ‘lock_1’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
         free ( lock_1 );
              ^
cc1: all warnings being treated as errors

gcc-4.9.0-pre9999 -Werror -pedantic -Wall -Wextra -std=gnu99 -pthread -pipe -O2
test.c -o test
>>
test.c: In function ‘func’:
test.c:44:17: error: ‘lock_1’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
                 free ( lock_1 );
                 ^
cc1: all warnings being treated as errors

gcc-4.10.0-pre9999 -Werror -pedantic -Wall -Wextra -std=gnu99 -pthread -pipe
-O2 test.c -o test
>>
test.c: In function ‘func’:
test.c:44:17: error: ‘lock_1’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
                 free ( lock_1 );
                 ^
cc1: all warnings being treated as errors
>From gcc-bugs-return-453391-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 06 14:13:21 2014
Return-Path: <gcc-bugs-return-453391-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31701 invoked by alias); 6 Jun 2014 14:13:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31664 invoked by uid 48); 6 Jun 2014 14:13:17 -0000
From: "luto at mit dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/56574] False possibly uninitialized variable warning
Date: Fri, 06 Jun 2014 14:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: luto at mit dot edu
X-Bugzilla-Status: NEW
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: <bug-56574-4-Rzy1XCgPyE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56574-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56574-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00473.txt.bz2
Content-length: 223

https://gcc.gnu.org/bugzilla/show_bug.cgi?idV574

--- Comment #10 from Andy Lutomirski <luto at mit dot edu> ---
See PR59500 for another example without &&.  I think I can reduce another test
case with only if and else.

[Bug middle-end/56574] False "may be uninitialized variable" warning (&& converted to &)

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
      Known to fail|                            |10.2.0, 11.0, 4.7.4, 4.8.4,
                   |                            |4.9.4, 5.5.0, 6.4.0, 7.2.0,
                   |                            |8.3.0, 9.1.0
                 CC|                            |msebor at gcc dot gnu.org
   Last reconfirmed|2013-03-11 00:00:00         |2021-3-26

--- Comment #12 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirming for GCC 11.

With a slightly tweaked test case and a patched GCC to print the conditions
under which it determines the variable is uninitialized the note after the
warning makes it clear even without looking at the dump that the warning is a
false positive.

$ cat pr56574.c && gcc -O2 -S -Wuninitialized -Wmaybe-uninitialized
-fdump-tree-uninit=/dev/stdout pr56574.c
int f (void);

void g (int i)
{
  int x;

  if (i == 0)
    x = f ();

  for (;;)
    {
    if (i == 0 && x)
      continue;

    if (i == 0)
      break;
  }
}

;; Function g (g, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)

0 dep_chains for phi_bb 4, use_bb 4:
        tmp chain = i_6(D) == 0
one_pred = i_6(D) == 0
pr56574.c: In function ‘g’:
pr56574.c:12:16: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   12 |     if (i == 0 && x)
      |                ^~
pr56574.c:5:7: note: when ‘i != 0’
    5 |   int x;
      |       ^
pr56574.c:5:7: note: ‘x’ was declared here
void g (int i)
{
  int x;
  _Bool _14;
  _Bool _15;
  _Bool _16;

  <bb 2> [local count: 79134772]:
  if (i_6(D) == 0)
    goto <bb 3>; [33.00%]
  else
    goto <bb 11>; [67.00%]

  <bb 11> [local count: 53020297]:
  goto <bb 4>; [100.00%]

  <bb 3> [local count: 26114475]:
  x_10 = f ();

  <bb 4> [local count: 79134772]:
  # x_11 = PHI <x_7(D)(11), x_10(3)>
  _14 = i_6(D) == 0;
  _15 = x_11 != 0;
  _16 = _14 & _15;

  <bb 5> [local count: 719407024]:

  <bb 6> [local count: 1073741824]:
  if (_16 != 0)
    goto <bb 10>; [33.00%]
  else
    goto <bb 7>; [67.00%]

  <bb 10> [local count: 354334800]:
  goto <bb 6>; [100.00%]

  <bb 7> [local count: 719407024]:
  if (i_6(D) == 0)
    goto <bb 8>; [11.00%]
  else
    goto <bb 9>; [89.00%]

  <bb 9> [local count: 640272252]:
  goto <bb 5>; [100.00%]

  <bb 8> [local count: 79134772]:
  return;

}

[Bug middle-end/56574] False "may be uninitialized variable" warning (&& converted to &)

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug tree-optimization/56574] False "may be uninitialized variable" warning (&& converted to &)

[coenraad at wish dot org.za]

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

dagelf <coenraad at wish dot org.za> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |coenraad at wish dot org.za

--- Comment #13 from dagelf <coenraad at wish dot org.za> ---
&& does not mean logical AND in gcc, it's a label. 

You should just be using &

[Bug tree-optimization/56574] False "may be uninitialized variable" warning (&& converted to &)

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to dagelf from comment #13)
> && does not mean logical AND in gcc, it's a label. 
> 
> You should just be using &

Huh? I think you are confused. && for an unary operator is taking the address
of a label in GNU C, but this is a && for a binary operator.