http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-12-17
CC| |hubicka at gcc dot gnu.org,
| |mkuvyrkov at ispras dot ru,
| |rguenther at suse dot de
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The testcase still has three OBJ_TYPE_REF.
# ivtmp_25 = PHI <ivtmp_24(3), 3(2)>
_18 = operator new (16);
MEM[(struct LinuxSocket *)_18].D.2889.D.2853._vptr.Stream = &MEM[(void
*)&_ZTV11LinuxSocket + 16B];
MEM[(struct LinuxSocket *)_18].D.2889.D.2854._vptr.Connection = &MEM[(void
*)&_ZTV11LinuxSocket + 72B];
LinuxSocket::open (_18);
goto <bb 6>;
<bb 5>:
__builtin_puts (&"got it"[0]);
<bb 6>:
_19 = MEM[(struct Stream *)_18]._vptr.Stream;
_20 = *_19;
_21 = OBJ_TYPE_REF(_20;(struct Stream)_18->0) (_18);
here LinuxSocket::open calls __builtin_puts and thus it is not pure and
therefore
basic folding can not propagate the known valud of vptr pointers.
We sort of agreed to not mark "NEW" as maloc by default, so I understand that
AA can not easily determine that puts is not touching _18.
Maxim, how this testcase passed with your patches?
Perhaps type based analysis can work out the type and can use the assumption
that in-place-new that would be required to change the type is not allowed to
change type of non-pod, but this kind of anlaysis is not in yet
(I have patch that would make this happen with ctor not being inlined)
