Hi,
the testcase:
struct S {
S() {}
};
S f() {
static S s;
return s;
}
fails with my last ipa-pure-const changes because variable S that is
TYPE_NEEDS_CONSTRCTING become read only. Old pure-const
implementation never
did this change because TYPE_NEEDS_CONSTRUCTIONG vars was left out
of analysis.
I am not too familiar with TYPE_NEEDS_CONSTRUCTING mechanism, but I
think in
this case S can become read only. The reason is that S is empty and
there is
nothing to construct. We compile the code into:
S f() ()
{
struct S D.2138;
bool D.2122;
int D.2130;
bool retval.1;
char D.2126;
char * _ZGVZ1fvE1s.0;
<bb 2>:
_ZGVZ1fvE1s.0_1 = (char *) &_ZGVZ1fvE1s;
D.2126_2 = *_ZGVZ1fvE1s.0_1;
if (D.2126_2 == 0)
goto <bb 3>;
else
goto <bb 5>;
<bb 3>:
D.2130_3 = __cxa_guard_acquire (&_ZGVZ1fvE1s);
if (D.2130_3 != 0)
goto <bb 4>;
else
goto <bb 5>;
<bb 4>:
__cxa_guard_release (&_ZGVZ1fvE1s);
<bb 5>:
return D.2138;
}
where __cxa_guard_acquire/__cxa_guard_release pair is locking the
empty
initialization code, at least in my understanding. Looking at places
TYPE_NEEDS_CONSTRUCTING is handled in backend, I think we should have
everything gimplified to level that we do not need to care about the
flag.
Note also that D.2138 is undefined. It is comming so from frontend
while in
older versions we at least used to initialize it from static s. I
wonder if
this is because the var is empty.