On Thu, 3 Feb 2022, Michael Matz wrote: > Hello, > > On Thu, 3 Feb 2022, Richard Biener 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. > > > > > > > > Distinguishing the two cases is also necessary for the PR90348 fix. > > > > > > (Just FWIW: I agree with the plan to have different types of CLOBBERs, in > > > particular those for marking births) > > > > > > A style nit: > > > > > > > tree clobber = build_clobber (TREE_TYPE (t)); > > > > + CLOBBER_MARKS_EOL (clobber) = 1; > > > > > > I think it really were better if build_clobber() gained an additional > > > argument (non-optional!) that sets the type of it. > > > > It indeed did occur to me as well, so as we're two now I tried to see > > how it looks like. It does like the following (didn't bother to > > replace all build_clobber calls but defaulted the parameter - there > > are too many). > > Except for this part I like it (I wouldn't call ca. 25 calls too > many). I often find optional arguments to be a long term maintenance > burden when reading code.
But I think in this case it makes clear that the remaining callers are un-audited - as Jakub said some of them may want to use a specific kind. I also wanted to make the patch small just in case we're considering the fix for GCC 12 ... > (And yeah, enum good, putting the enum to tree_base.u, if it works, > otherwise use your bit shuffling) It seems to. Updated patch in testing. Richard.
