[Bug c/65812] New: gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[Bug c/65812] New: gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[joe at perches dot com]

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

            Bug ID: 65812
           Summary: gcc 4.9.1 doesn't warn about uninitialized variable
                    use declared in a switch/case statement when compiled
                    with -O
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joe at perches dot com

Created attachment 35365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35365&action=edit
sample code

Here is a small example:

$ cat t.c
struct foo {
       int bar[100];
};

void foo_1(void)
{
    unsigned int m;
    extern struct foo *array[100];
    struct foo *a = array[m];

    a = a;
}

void foo_2(void)
{
    int i = 1;

    switch (i) {
    case 1: {
        unsigned int m;
        extern struct foo *array[100];
        struct foo *a = array[m];

        a = a;
        break;
    }
    }
}

$

gcc warns properly about both foo_1 and foo_2 without -O

$ gcc -c -Wall t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
  struct foo *a = array[m];
              ^
t.c: In function ‘foo_2’:
t.c:21:15: warning: ‘m’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   struct foo *a = array[m];
               ^
$

but gcc warns about foo_1 but not foo_2 with -O

$ gcc -c -Wall -O t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
  struct foo *a = array[m];
              ^

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)
>From gcc-bugs-return-484051-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 20 10:38:10 2015
Return-Path: <gcc-bugs-return-484051-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 38951 invoked by alias); 20 Apr 2015 10:38:10 -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 38824 invoked by uid 48); 20 Apr 2015 10:38:05 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers
Date: Mon, 20 Apr 2015 10:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
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-65673-4-PPCeQshOyF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65673-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65673-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: 2015-04/txt/msg01603.txt.bz2
Content-length: 835

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The following seems to work and regtests cleanly.  But I have to say I'm
somewhat dubious now about changing this at all.  I suppose I should try to
compile e.g. the Linux kernel with this patch and see if anything breaks.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index ebe4c73..590e235 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -7565,7 +7565,7 @@ pop_init_level (location_t loc, int implicit,
       /* Silently discard empty initializations.  The parser will
      already have pedwarned for empty brackets.  */
       if (integer_zerop (constructor_unfilled_index))
-    constructor_type = NULL_TREE;
+    /* Do nothing.  */;
       else
     {
       gcc_assert (!TYPE_SIZE (constructor_type));

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-20
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is because at the point where we warn we don't know that the code is
executed unconditionally and with optimization we don't warn about
maybe-uninitialized uses early.

Late we have removed all code as dead and thus do not warn either.

I'd say it works as intended (even though surprising).

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[joe at perches dot com]

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

--- Comment #3 from Joe Perches <joe at perches dot com> ---
Thank you both for your very prompt replies.

It might be useful to have a -Wunused-eliminated type extra warning
though that might be very noisy.

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So shouldn't this be INVALID rather than NEW?

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure.