Hi, On Wed, 20 Feb 2019, Jeff Law wrote:
> No, I'm saying the distinction between maybe and always uninitialized is > a false distinction. Code duplication can easily take something that > triggers a "maybe" warning and turn it into a "always" warning. The > distinction between them is just bogus. > > To take your example > > if (a) > b = 42 > ... > if (a) > f(b); > > Can be rewritten as > > if (a) { > b = 42 > [ copy of ...] > f (b); > } else { > ... > f (b); // xxx > } No, it cannot. It would introduce a call to f(b) in a path (at xxx) where it wasn't before. Any transformation that transforms maybe-uninit into must-uninit is either wrong or introduces more-obviously-dead-than-before code, like in this variant of yours that is correct: if (a) { b = 42 [ copy of ...] f (b); } else { ... if (a) // clearly false, as dominated by if (!a) f (b); // hence more obviously dead than in original code } > x4 = PHI (x0(D), x1, x2, x3) > use x4; > > That's a maybe uninitialized warning by way of the value flow of x0 > through the PHI into x4. So clearly the use of x4 when reached via edge using x0(D) must be dead (or we have a real uninit use) but we can't differ because there's only one use of x4 statically ... nevertheless it's unobviously-dead. > Which we then simplify into > > BB: > use x0(D) > goto join > > BB: > x4 = PHI (x1, x2, x3) > use x4 > goto join And this makes the uninit use of x0(D) more obviously dead because now the problematic and non-problematic uses are separated. So, the transformation introduced more-obviously-dead code, which it just as well could have removed/not generated, getting rid of the must-uninit warning. I guess what I'm saying is that whenever a transformation is about to introduce a must-uninit from a maybe-uninit that instead all paths leading to that must-uninit should be removed instead. > That changes the warning from a maybe-uninitialized into an always > uninitialized. Note that we still may or may not reach the use at > runtime. THe distinction between maybe and always is just bogus. I think as stated that's a bit extreme :) On user code before optimization the distinction is useful. The problem stems from us generating warnings somewhen in the middle of the optimization pipeline. As long as we continue doing that we will always have these different opinions about what is or isn't rightfully a maybe-uninit or not :-/ Ciao, Michael.