https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Changing what types have TREE_ADDRESSABLE flag on it would cause significant
ABI changes, that is not what we can do.
Widget above does not have trivial default constructor, but has trivial copy
constructor and trivial destructor, it certainly can be copied.
Consider adjusted testcase:
struct Widget {
Widget();
long i = 1;
long j = 2;
};
Widget *global = nullptr;
Widget::Widget() { global = this; }
[[gnu::noipa]] Widget make() { return Widget(); }
void g() { global->i = 42; }
int main() {
Widget w = make();
int i = w.i;
g();
return (i == w.i);
// Does this need to be reloaded and
// compared? or is it obviously true?
}
On x86_64, this Widget is returned in registers, so the assumptions the
testcase has
look wrong to me, dereferencing global when the return went out of scope looks
UB to me.
On i686, this Widget is returned in memory. Is the testcase valid there or UB
as well?
Jason, thoughts on this?
If the above testcase is for some reason valid conditionally (on some targets,
not on others, depending on calling conventions), I think we could check
TREE_ADDRESSABLE on the called function RESULT_DECL if it has some extra flag
set by the FE that there was guaranteed copy ellision (and assume worst case if
we don't see the called function (we then don't know if it has been compiled by
C or C++ etc.) or it has noipa attribute).
