On Thu, 3 Feb 2022, Richard Sandiford wrote: > 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.
constructors are tcc_exceptional but since they are used where tree operands reside they need to be compatible to EXPR_P and thus various things like TREE_SIDE_EFFECTS need to work. Which means, we can't. Richard.
