https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've just tried:
int i, j, k;
void *
foo ()
{
i = 1;
j = 2;
void *p = __builtin_operator_new (32);
j = 3;
k = i;
return p;
}
void *
bar ()
{
i = 1;
j = 2;
void *p = __builtin_malloc (32);
j = 3;
k = i;
return p;
}
void *
baz ()
{
i = 1;
j = 2;
void *p = ::operator new (32);
j = 3;
k = i;
return p;
}
and it seems that both g++ and clang++ for the malloc case optimize j = 2; away
and k = i; into k = 1;, i.e. malloc is assumed not to read nor write global
state visible to the program except the allocation itself.
While __builtin_operator_new results just in k = i; to k = 1; optimization and
not the removal of j = 2; (i.e. __builtin_operator_new is assumed not to modify
global state but is assumed to read it).
And ::operator new isn't optimized either way, no matter whether with
-fassume-sane-operator-new or -fno-assume-sane-operator-new (those flags don't
change foo behavior either).
So I wonder if we really should follow what clang++ does because it doesn't
make much sense, lacks consistency and design.
