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. :-)) 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
