Hi,<div><br></div><div>The attached patch fixes a bug in the uninitialized variables warning in the handling of compound assignments. We previously would not report an issue with this code:</div><div><br></div><div><div>int compound_assign(int *arr, int n) {</div>
<div>  int sum;</div><div>  for (int i = 0; i < n; ++i)</div><div>    sum += arr[i];</div><div>  return sum / n;</div><div>}</div></div><div><br></div><div>The problem is that, in the CFG's ordering, we see the DeclRefExpr for 'sum' before the DeclRefExpr for 'arr', so we've already handled 'sum' (and decided that it escapes the analysis and must be initialization) before we see the BinaryOperator and try to treat it as a use.</div>
<div><br></div><div>The patch replaces the 'track the last DeclRefExpr we saw' technique with a separate pass to classify the DeclRefExprs as use or initialization. Fixing this exposed some "false" positives on some benchmarking code which looks like:</div>
<div><br></div><div>void f() {</div><div>  volatile int n;</div><div>  for (int i = 0; i < N; ++i)</div><div>    n += f();</div><div>}</div><div><br></div><div>... so the patch classifies compound-assignments as neither initialization nor use (it leaves the variable uninitialized if it was before, and leaves it initialized if it was before).</div>
<div><br></div><div>As a minor tweak, I've also given the same treatment to const& function parameters: these are no longer treated as initializing the argument (but nor are they treated as uses, since that introduces some false positives in my testing corpus).</div>
<div><br></div><div>Please review!</div><div><br></div><div>Thanks,</div><div>Richard</div>