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

Reply via email to