[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

["gdr at cs dot tamu dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #149 from gdr at cs dot tamu dot edu  2007-05-23 23:56 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #140 from mark at codesourcery dot com  2007-05-23 21:07
-------
| Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
|  new does not change the dynamic type as it should
| 
| rguenth at gcc dot gnu dot org wrote:
| 
| > <quote>
| > Gaby's claim is that given an arbitrary
| > pointer "p", saying:
| > 
| >  (int *)p = 3;
| > 
| > is the same as saying:
| > 
| >  *(new (p) int) = 3;
| > 
| > That makes life for the optimizers much, much harder.
| > </quote>
| > 
| > I say so as well (that those are the same), but I don't agree that this
| > makes life for optimizers much harder.
| 
| Placement new is rare; assignments to pointers are everywhere.

Naked placement new may be rare; but, placement new is general are not
rare because of the STL-style containers and algorithms.

| 
| Note that the first case does not need to use an explicit cast.  In a
| function:
| 
|   void f(int *p) {
|     *p = 3;
|   }
| 
| under Gaby's interpretation, we cannot be sure that "p" points to an
| "int" before this function, so we can't be sure the write to "*p"
| doesn't clobber memory of other types.

Note that is is a problem only with PODs -- because only those can
appear in unions.  That does not help much, but it is a distinction
you have to make when you're considering what the standard says.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286