This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 May 2007 11:14:20 -0000
- Subject: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
- References: <bug-29286-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 -------
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
we'd trust it, instead of using TBAA to say "but it shouldn't". Like for
the (invalid)
int foo(void *p)
{
double *q = p;
int *r = p;
*q = 1.0;
return *r;
}
where we correctly figure that
Points-to sets
q_2 = same as p
r_3 = same as p
but still we get (with -fstrict-aliasing)
<bb 2>:
q_2 = (double *) p_1(D);
r_3 = (int *) p_1(D);
# SMT.4_7 = VDEF <SMT.4_6(D)>
*q_2 = 1.0e+0;
# VUSE <SMT.5_8(D)>
D.1641_4 = *r_3;
which just for the point to make the invalid input produce unexpected
output is possibly creating many of the hard-to-fix issues like this one.
Danny, how easy is it to "fix" the above? It looks like another
attractive solution to this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286