On Sat, Dec 15, 2012 at 5:09 AM, Jeff King <p...@peff.net> wrote:
> I always compile git with "gcc -Wall -Werror", because it catches a lot
> of dubious constructs, and we usually keep the code warning-free.
> However, I also typically compile with "-O0" because I end up debugging
> a fair bit.
> Sometimes, though, I compile with -O3, which yields a bunch of new
> "variable might be used uninitialized" warnings. What's happening is
> that as functions get inlined, the compiler can do more static analysis
> of the variables. So given two functions like:
> int get_foo(int *foo)
> if (something_that_might_fail() < 0)
> return error("unable to get foo");
> *foo = 0;
> return 0;
> void some_fun(void)
> int foo;
> if (get_foo(&foo) < 0)
> return -1;
> printf("foo is %d\n", foo);
> If get_foo() is not inlined, then when compiling some_fun, gcc sees only
> that a pointer to the local variable is passed, and must assume that it
> is an out parameter that is initialized after get_foo returns.
> However, when get_foo() is inlined, the compiler may look at all of the
> code together and see that some code paths in get_foo() do not
> initialize the variable. And we get the extra warnings.
- Any __attribute__ or #pragma to aid flow analysis (or would gcc dev be
willing to add one)?
- Maintain a list of false positives and filter them out from gcc output?
And if we do this, should we support other compilers as well? I tried
clang once a long while ago and got a bunch of warnings iirc.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html