Bug 30542

Summary: missing uninitialized variable warning (CCP)
Product: gcc Reporter: Dave <david.cuthbert>
Component: cAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: christoph.mallon, david.cuthbert, dberlin, dhill, fredrik, gcc-bugs, hp, jellegeerts, jens.mueller, manu, mark, mueller, muntyan, P.Schaffnit, pinskia, satyam, thutt
Priority: P3    
Version: 4.1.1   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2009-02-07 21:12:23
Bug Depends on: 18501    
Bug Blocks:    
Attachments: foo.i file

Description Dave 2007-01-22 14:29:44 UTC
Not sure if this is a bug, or I'm just missing some option or other, but I appear to be missing "uninitialized variable" warnings (in some cases, but not others) when compiling C such as the following:

#include <stdio.h>

int
main(void)
{
    int foo;
    int i;

    i = 1;
    while (i) {
        if (i == 10) {
            foo = 50;
        }

        /* Uncomment this block and warnings miraculously appear
        if (i == 15) {
            foo = 52;
        }
        */

        if (foo) {
            printf("%d\n", foo);
        }

        ++i;
        if (i > 20) {
            break;
        }
    }
    
    return 0;
}

I'm using the following to compile (which gives no output from gcc):
- /usr/bin/gcc -Wall -W -ansi -pedantic -O2 -o foo foo.c

And output from gcc -v gives this:
: gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r3)


Someone also tried the same code on 4.1.2 and got the same results (if that helps).
Comment 1 Dave 2007-01-22 14:31:07 UTC
Created attachment 12931 [details]
foo.i file

Adding foo.i file
Comment 2 Andrew Pinski 2007-01-22 17:27:17 UTC

*** This bug has been marked as a duplicate of 22456 ***
Comment 3 Yevgen Muntyan 2007-01-23 03:09:24 UTC
Is it really quite as 22456? That bug is about variable used for initializing itself, and really strange do-nothing code, while this one is straightforward use of unitialized variable:

int main (void)
{
  int i, foo;
  for (i = 0; i < 10; i++)
  {
    if (i > 5)
      foo = 8;
    printf ("%d\n", foo); /* uninitialized foo is printed six times */
  }
}

or this one:

#include <stdio.h>

int func (void)
{
    return 0;
}

int main (void)
{
    int foo;

    if (func ())
        foo = 8;

    printf ("%d\n", foo);
    return 0;
}

Sorry for pain if this really a duplicate.
Comment 4 Manuel López-Ibáñez 2007-08-15 15:21:04 UTC
(In reply to comment #3)
> Is it really quite as 22456? That bug is about variable used for initializing
> itself, and really strange do-nothing code, while this one is straightforward
> use of unitialized variable:
> 
> int main (void)
> {
>   int i, foo;
>   for (i = 0; i < 10; i++)
>   {
>     if (i > 5)
>       foo = 8;
>     printf ("%d\n", foo); /* uninitialized foo is printed six times */
>   }
> }
 
I get ten times 8 printed. Roughly, an optimisation pass is assuming that the initial value of foo is 8 (remember, undefined means we can assume whatever), so foo is completely removed. Believe me, the optimisation is valid and beneficial and in many situations the uninitialised value is never used (if we were to warn, it will be a false positive). Unfortunately, this is not one of these cases.
Comment 5 Manuel López-Ibáñez 2009-02-07 21:11:57 UTC
This is clearly CCP. Probably a duplicate of 18501, better double check if 18501 is ever fixed.

The reason why uncommenting the block of code brings back the warning is that CCP cannot assume that foo is just 50 because it could also be 52, so it doesn't remove foo and then the late pass kicks in and detects a default definition in the PHI node. I bet the warning given is "may be used".

Comment 6 Richard Biener 2009-06-17 12:06:56 UTC

*** This bug has been marked as a duplicate of 18501 ***