On Thu, 18 Sep 2025, Jakub Jelinek wrote:
> On Thu, Sep 18, 2025 at 06:54:06PM +0200, Jason Merrill wrote:
> > > There are some regressions caused by the removal of {CLOBBER(bob)}
> > > clobbers from the start of certain constructors, e.g. one testcase has
> > > struct A
> > > {
> > > int f,g;
> > > A() { f = g; // { dg-warning "g. is used uninitialized" } }
> > > } a;
> > > and this doesn't warn anymore for any C++ mode. Wonder what we could
> > > do for the warnings, for code generation we have to assume the code
> > > can read members in *this (for C++26 read there .DEFERRED_INIT, for
> > > older C++ versions with -flifetime-dse=2 {CLOBBER(bob)}).
> > > Perhaps we should add some artificial attribute to the functions we'd
> > > add the -flifetime-dse=2 clobber to and treat *this reaching the start
> > > of the function for those specially in the uninit pass?
> >
> > Or some way to indicate in GIMPLE that whatever value is there, it's
> > poisoned?
>
> Some new ifn which is say:
> *this = .POISON (this);
> or
> *this = .POISON (*this);
> would be an option (which would expand to nothing if the pointers are the
> same), dunno what would be easier to implement though.
> I'll try artificial attribute on the this PARM_DECL.
>
> Richi, what is your preference from the middle-end POV?
> Just a way to force -Wuninitialized/-Wmaybe-uninitialized warnings on
> reads but similarly to .DEFERRED_INIT which sets to specific bytes
> use whatever was in memory before.
So a CLOBBER doesn't do because it might cause earlier writes to be
DSEd (even if it itself doesn't alter storage)?
I wonder if we can re-use .DEFERRED_INIT with a special mode here?
Again I'm noticing we do not document internal-functions anywhere,
in particular their expected signature or semantics ... :/
>From internal-fn.cc it seems we have an INIT_TYPE parameter, can
we add AUTO_INIT_KEEP_OLD or is AUTO_INIT_UNINITIALIZED already
doing what we want here?
Richard.
