[Bug c/54554] New: Undetected use of uninitialized variable

[Bug c/54554] New: Undetected use of uninitialized variable

[dpapavas at gmail dot com]

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

             Bug #: 54554
           Summary: Undetected use of uninitialized variable
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dpapavas@gmail.com


Created attachment 28176
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28176
The output of the command line used to compile the snippet to stderr.

When compiling the snippet below:

---8<------8<------8<------8<------8<------8<------8<------8<---

extern int printf (__const char *__restrict __format, ...);

int main()
{
    int j;

    for (j = 0 ; j < 10 ; j += 1) {
        int i;

        printf ("%d\n", i);
        i = 1;
    }

    return 0;
}

---8<------8<------8<------8<------8<------8<------8<------8<---

GCC fails to detect the use of an uninitialized variable.  The command line
used to compile it is:

gcc -v -save-temps -Wall -Wextra -O0 -g -ansi -pedantic foo.c

Output to stderr has been attached.  I won't attach the .i file as it simply
seems to contain a copy of the source.  Let me know if you need it.

Bug 52523 seems to be related if not identical but I'm still submitting this as
this is C code not C++.

[Bug c/54554] Undetected use of uninitialized variable

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-12
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-12 09:47:16 UTC ---
By means of the assignment i becomes an induction variable and at -O0 we do
not warn for "maybe used uninitialized".  With optimization the use is
constant-propagated out.

Thus, this is a known issue, not really the same as PR52523

[Bug c/54554] Undetected use of uninitialized variable

[dpapavas at gmail dot com]

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

--- Comment #2 from Dimitris Papavasiliou <dpapavas at gmail dot com> 2012-09-12 10:19:20 UTC ---
Specifying -O does indeed produce a warning if i is not assigned a constant
value (for instance i = rand(); ).  Omitting -O and specifying
-Wmaybe-uninitialized does not produce anything though.  Does that mean that
warnings about possibly uninitialized variables are not supported at all, even
if explicitly requested by the user when not optimizing?  If that is the case
then perhaps this should be documented in the manual.  The latest version just
mentions this for -Wmaybe-uninitialized:

"This warning is enabled by -Wall or -Wextra."

[Bug c/54554] Undetected use of uninitialized variable

[manu at gcc dot gnu.org]

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

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

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

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-04 10:27:53 UTC ---
GCC should warn without optimization since the code is always executed. There
are several issue conflated here that prevent warning, but the most crucial is
that GCC does not know that the loop is always executed at least once.

[Bug c/54554] Undetected use of uninitialized variable

[dpapavas at gmail dot com]

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

--- Comment #4 from Dimitris Papavasiliou <dpapavas at gmail dot com> 2013-01-04 12:41:02 UTC ---
Still even without knowing that a "may be used uninitialized" warning can be
issued in any case.

[Bug c/54554] Undetected use of uninitialized variable

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-04 12:49:39 UTC ---
(In reply to comment #4)
> Still even without knowing that a "may be used uninitialized" warning can be
> issued in any case.

GCC does not warn if it can prove that the code is never executed. But it
doesn't even try to prove that without optimization enabled, so it doesn't
warn. Otherwise, it would warn for obvious things like:

int d;
if (0) return d;

and people will complain.

[Bug c/54554] Undetected use of uninitialized variable

[dpapavas at gmail dot com]

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

--- Comment #6 from Dimitris Papavasiliou <dpapavas at gmail dot com> 2013-01-04 14:50:32 UTC ---
Well this seems to be a core decision regarding the way GCC warnings work
(which probably has more far-reaching consequences) but just for the sake of
argument, I don't see why people should complain even in such a case.  The only
use I can think of for code such as the above is temporarily switching of a
statement but, apart from the fact that this can be more efficiently done with
preprocessor directives, the thing is that temporarily disabling a statement in
this way is meaningful if it is expected that it will be re-enabled at some
time in the future.  If that would lead to broken code there's not much of a
point.

I don't mean to dictate the coding-style others should use of course but still
it seems to me like a small price to pay for avoiding obscure stochastic bugs
that can take hours of debugging to locate (especially given the fact that
there's good reason to disable optimizations when debugging code).

[Bug c/54554] Undetected use of uninitialized variable

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominik.muth at gmx dot de

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
*** Bug 60791 has been marked as a duplicate of this bug. ***

[Bug c/54554] Undetected use of uninitialized variable

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Dimitris Papavasiliou from comment #6)
> I don't mean to dictate the coding-style others should use of course but
> still it seems to me like a small price to pay for avoiding obscure
> stochastic bugs that can take hours of debugging to locate (especially given
> the fact that there's good reason to disable optimizations when debugging
> code).

It should be possible to run the pass that triggers -Wmaybe-uninitialized
warning without optimization, but it will be very noisy. You could explore the
option of keeping it disabled at -O0 unless the user requests it by an explicit
-Wmaybe-uninitialized. But you should run some tests to see how noisy/useful
that would be. My guess is that a lot more noisy than useful.
>From gcc-bugs-return-448597-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 09 11:08:07 2014
Return-Path: <gcc-bugs-return-448597-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32235 invoked by alias); 9 Apr 2014 11:08:07 -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 32185 invoked by uid 48); 9 Apr 2014 11:08:02 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/60411] Ada bootstrap failure on ARM
Date: Wed, 09 Apr 2014 11:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60411-4-B8wPT4f0Bx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60411-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60411-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-04/txt/msg00617.txt.bz2
Content-length: 493

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`411

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The compiler builds happily now.

Great, thanks for the quick feedback.

> It started right into ACATS testing and has passed the first 3 chapters
> flawlessly (with the current setup ACATS takes hours because each test is
> SCP'd/SSH'd to the device, but I'm going to improve the remote testing soon).

Please post the definitive results here when you have them, TIA.

[Bug c/54554] Undetected use of uninitialized variable

[dominik.muth at gmx dot de]

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

--- Comment #9 from Dominik Muth <dominik.muth at gmx dot de> ---
Please note that in Bug 60791 no warning is given even with -O3 (except when
using a legacy version of gcc).

[Bug tree-optimization/54554] fails to warn for uninitialized var within loop always taken at -O0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |13.0
   Last reconfirmed|2012-09-12 00:00:00         |2022-8-29

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Re-confirmed.