Hi, Richard, > On Jul 1, 2021, at 11:23 AM, Richard Sandiford <richard.sandif...@arm.com> > wrote: > > Michael Matz <m...@suse.de> writes: >> Hello, >> >> On Thu, 1 Jul 2021, Richard Sandiford wrote: >> >>> Well, it does feel like this is pressing the reset button on a thread >>> whose message count is already in the high double figures. There's a >>> risk that restarting the discussion now is going to repeat a lot of the >>> same ground, probably at similar length. (But I realise that the sheer >>> length of the thread is probably also the main reason for not having >>> followed it closely. :-)) >> >> Yeah, I thought of not sending the mail because of that. But it itched >> too itchy ;-) >> >>> (2) continue to treat uses of uninitialised automatic variables as >>> (semantically) undefined behaviour >>> >>> When this was discussed on the clang list, (2) was a key requirement >>> and was instrumental in getting the feature accepted. >>> ... >>> since the behaviour is at least deterministic. But from a debugging QoI >>> perspective, this should not happen. We should generate the same code >>> as for: >>> >>> int foo = <fill-pattern>; >>> if (flag) >>> foo = 1; >>> x = foo; >>> >>> However, because of (2), we should still generate a >>> -Wmaybe-uninitialized warning for the “x = foo” assignment. >>> >>> This is not a combination we support at the moment, so something needs >>> to give. The question of course is what. >> >> Nothing needs to give. You add the initialization with <fill-pattern>, >> _without an uninitialized use_, i.e. just: >> >> foo = .deferred_init(pattern) >> >> or the like. Then you let the optimizers do their thing. If 'foo' is >> provably initialized (or rather overwritten in this setting) on all paths >> from above init to each use, that init will be removed. IOW: if the init >> remains then not all paths are provably initializing. I.e. the warning >> code can be triggered based on the simple existence of the deferred_init >> initializer. >> >> Basically the .deferred_init acts as a "here the scope starts" marker. >> That's indeed what you want, not the "here the scope ends" clobber. If a >> use reaches the scope-start marker you have an (possibly) uninitialized >> use and warn. >> >> (I'm obviously missing something because the above idea seems natural, so >> was probably already discussed and rejected, but why?) > > The hope was that we wouldn't even need to treat DEFERRED_INIT specially > when analysing uninitialised uses. The argument would be a standard > uninitialised use, just like any other. > > But that was before this issue came up. It also sounds like Qing is now > handling DEFERRED_INIT specially anyway. (I've lost track of why, > but see above about reopening that discussion. :-))
The reason I handled DEFERRED_INIT specially in uninitialized warning analysis was because only relying on the uninitialized argument in the .DEFERRED_INIT call was not enough for the analysis. The special handlings was introduced in the 1st version of the patch. (I don’t remember the exact details on why it would not work without specially handling .DEFERRED_INIT) Thanks Qing > > So it sounds like that's indeed where we've ended up. I don't think > the original principle was inherently bad though. > > Thanks, > Richard
