Re: [net-next PATCH] ipv6: fix false-postive maybe-uninitialized warning

On Fri, Aug 18, 2017 at 7:49 PM, David Miller [off-list ref] wrote:

From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 18 Aug 2017 13:34:22 +0200

quoted

This kind of warning involving an unlock between variable initialization
and use is relatively frequent for false-positives. I should try to
seek clarification from the gcc developers on whether this can be
improved.

This will have to do for now I suppose.

I guess the issue is that if the local variable ever sits on the stack
then the memory barriers in the locks block the full dataflow
analysis.

But this makes no sense from a dataflow perspective.  Even if the
local variable has a stack slot, there is no "escapability" of that
memory addres to foreign modifications.

If I had a nickel for every uninitialized variable warning we had to
work around....

Since this pattern has come up so often, I spent most of my working
day today on a reduced testcase, and ended up with this surprising
snippet:

int f(void);
static inline void rcu_read_unlock(void)
{
        static _Bool __warned;
        if (f() && !__warned && !f()) {
                __warned = 1;
        }
}
int inet6_rtm_getroute(void)
{
        int dst;
        int fibmatch = f();

        if (!fibmatch)
                dst = f();
        rcu_read_unlock();
        if (fibmatch)
                dst = 0;

        return dst;
}

So at least in this particular case, the culprit is not actually
a memory barrier, but RCU_LOCKDEP_WARN(). A related
problem is __branch_check__()/__trace_if().

While the maybe-uninitialized warnings are unreliable by
definition, I think that case really should be understood by gcc.

I looked through the gcc bug database which has countless
entries but doesn't seem to have this one yet, so I opened
a new bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897

Unfortunately the basic behavior shows up in gcc-4.7 already,
so it has no chance of getting fixed on older compilers.

        Arnd