https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #6) > The problem is that when the address of a variable escapes, because GCC > doesn't track when, when the function from which it escapes calls another > that might access the escaped variable, the warning (as a result of relying > on the conservative assumptions the optimizers must make) assumes the called > function initializes the variable. Another example of this is function h() > below. I don't think these are equivalent testcases. It is OK to assume that the invisible function initializes the variable. The problem arises when there is a path that never calls the function but GCC does not see that. The key here is the logical operator splits the possible paths in two. In one of the paths, b (comment #5) is never initialized, no matter what you assume about f(). It also happens with a simple if(): int f (int*); int g(void); int foo (void) { int b; if (g()) { f(&b); } return b; } However, a similar construct without &b works: int g(void); int foo (void) { int b; if (g()) { b = g(); } return b; } If you look at the VOPs, there is a chain that goes from the VUSE of b to the VDEF<(D)> through at least one PHI node. The "return 0" is problematic because CPP (PR18501) will trigger and mess up things even more. But the above testcases avoid PR18501 and still show this bug.