Richard Biener <rguent...@suse.de> writes: > On Wed, 2 Feb 2022, Michael Matz wrote: > >> Hello, >> >> On Wed, 2 Feb 2022, 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. >> > >> > 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). With CLOBBER_BIRTH added for the fix for PR90348 > the enum would be constructed like > > #define CLOBBER_KIND(NODE) \ > ((clobber_kind) (CONSTRUCTOR_CHECK (NODE)->base.private_flag << 1 > | CONSTRUCTOR_CHECK (NODE)->base.protected_flag)) > > or so (maybe different dependent on bitfield endianess to make > extracting the two adjacent bits cheap). That would leave us space > for a fourth state. > > So do you think that makes it nicer? What do others think?
This way looks cleaner to me FWIW. Which arm of tree_base::u do constructors use? If we need a 2-bit enum then maybe we can carve one out from there. Thanks, Richard