On Wed, 2 Feb 2022, Jakub Jelinek wrote: > On Wed, Feb 02, 2022 at 03:42:48PM +0100, Richard Biener via Gcc-patches > wrote: > > This adds a flag to CONSTRUCTOR nodes indicating that for > > clobbers this marks the end-of-life of storage as opposed to > > just ending the lifetime of the object that occupied it. > > The dangling pointer diagnostics uses CLOBBERs but is confused > > by those emitted by the C++ frontend for example which emits > > them for the second purpose at the start of CTORs. The issue > > is also appearant for aarch64 in PR104092. > > I think many further build_clobber calls actually should build > those EOL clobbers, I think we'd need to go through them one by one and see > what kind of clobber it is. > E.g. I think all of omp-low.cc build_clobber calls are like that.
Yeah, there may be others that also end lifetime of the storage. It should be pretty safe since the only consumer after this patch is the access warning. > C++ FE indeed emits some clobbers at the start of ctors with > -flifetime-dse=2, but others e.g. at the end of dtors, dunno about those, > though maybe the object doesn't go out of scope at that point yet. > What about expansion and tree-ssa-live.cc, should those keep doing > what it does and not ignore clobbers that aren't CLOBBER_MARKS_EOL? Yes. Basically EOL clobbers act as regular clobbers _plus_ they also note the end of life of the underlying storage, so treating those like regular clobbers is safe, likewise it's not a regression to not ignore !CLOBBER_MARKS_EOL clobbers elsewhere and I'd rather have testcases showing the current behavior is wrong for those than changing other places. The inliner and CCP cases I ran into when fixing PR90348, I did not run into any others sofar. Richard.
