User account creation filtered due to spam.

Bug 30542 - missing uninitialized variable warning (CCP)
Summary: missing uninitialized variable warning (CCP)
Status: RESOLVED DUPLICATE of bug 18501
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 18501
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-22 14:29 UTC by Dave
Modified: 2009-06-17 12:06 UTC (History)
17 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-02-07 21:12:23


Attachments
foo.i file (3.11 KB, text/plain)
2007-01-22 14:31 UTC, Dave
Details

Note You need to log in before you can comment on or make changes to this bug.
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 ***