GCC Bugzilla Bug 36550

Yet another one. It behaves the same for 4.1.2 and current trunk.

$ gcc -Os -Wuninitialized -c uninit-J.c
uninit-J.c: In function 'pr':
uninit-J.c:7: warning: 'bug' may be used uninitialized in this function

$ cat uninit-J.c
/* { dg-do compile } */
/* { dg-options "-Os -Wuninitialized" } */
void bail(void) __attribute__((noreturn));
unsigned check(void);
int pr(char**argv)
{
        char *bug;
        if (check()) {
                if (*argv)
                        bug = *++argv;
        } else {
                bug = *argv++;
                if (!*argv)
                        bail();
        }
        /* now bug is set except if (check() && !*argv) */
        if (check()) {
                if (!*argv)
                        return 0;
        }
        /* if we ever get here then bug is set */
        return *bug != 'X';
}

check() can return 1 on the first call and 0 on the second and if *argv is NULL
then then "bug" will be used uninitialized.

(In reply to comment #1)
> check() can return 1 on the first call and 0 on the second and if *argv is NULL
> then then "bug" will be used uninitialized.

right, but this doesn't matter here. Better testcase:

/* { dg-do compile } */
/* { dg-options "-Os -Wuninitialized" } */
void bail(void) __attribute__((noreturn));
unsigned once(void);
int pr(char**argv)
{
        char *bug;
        unsigned check = once();
        if (check) {
                if (*argv)
                        bug = *++argv;
        } else {
                bug = *argv++;
                if (!*argv)
                        bail();
        }
        /* now bug is set except if (check && !*argv) */
        if (check) {
                if (!*argv)
                        return 0;
        }
        /* if we ever get here then bug is set */
        return *bug != 'X';
}

This really needs conditional phis so ...

*** Bug 38037 has been marked as a duplicate of this bug. ***

*** Bug 39088 has been marked as a duplicate of this bug. ***

*** Bug 27289 has been marked as a duplicate of this bug. ***

*** Bug 39133 has been marked as a duplicate of this bug. ***

I added this as Problem 5 in the wiki:

http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

I do not really understand problem 5 for the case when the only dependancy for
the code-path check is a local variable. In this case the value cannot be
change by any other code than existing between the two checks, so this case
should be handled reliable for sure. Of course this is not possible with global
oder class variables which might be affected by some other thread.

(In reply to comment #9)
> I do not really understand problem 5 for the case when the only dependancy for
> the code-path check is a local variable. In this case the value cannot be
> change by any other code than existing between the two checks, so this case
> should be handled reliable for sure.

Should? I guess you meant "could". Because it is obviously not handled right
now at the moment of warning.

That page simply lists causes, testcases and possible solutions for existing
problems. As always, contributions are welcome.