[lkml]   [2017]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [net-next PATCH] ipv6: fix false-postive maybe-uninitialized warning
On Fri, Aug 18, 2017 at 7:49 PM, David Miller <> wrote:
> From: Arnd Bergmann <>
> Date: Fri, 18 Aug 2017 13:34:22 +0200

>> 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

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();
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:

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


 \ /
  Last update: 2017-08-18 21:47    [W:0.041 / U:4.488 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site