[Bug rtl-optimization/83367] static global constructors stack memory corruption

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83367

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Dale Weiler from comment #5)
> Except they are referenced via their this pointer (which should alias the
> static storage in that translation unit). I don't see how this is any
> different than having a static variable in a translation unit and returning
> it in a function that references it in that same translation unit. The
> constructor in this case is compiled in the tests translation unit and
> references it. I think the problem has to do with move construction, since
> if you provide a move constructor for the cTest itself gcc seems to do the
> right thing.

static cTest a = cTestRegister( nullptr, "a" ) + [](cTest*){};

There we have assignment of a function operator[] to variable 'a'. In that case
we really know there's not taken a reference to variable 'a' and thus trivially
not needed. Thus we can use a temporary storage for result of the operator[].

I must admit that usage of a move constructor changes cTestRegister::operator+:

cTest cTestRegister::operator+(void (*)(cTest*)) const (const struct
cTestRegister * const this, void (*<T85c>) (struct cTest *) pfnTest)
{
  const char * _1;
  const char * _2;

  <bb 2> [100.00%]:
  _1 = this_4(D)->m_pchRoot;
  _2 = this_4(D)->m_pchName;
  cTest::cTest (&<retval>, _1, _2, pfnTest_5(D));
  return <retval>;

}

Here &<retval> is also a temporary as the function invocation:
cTestRegister::operator+ (&D.2547, _FUN); [return slot optimization]

does not use LHS, thus it uses a random storage I guess.