From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26084 invoked by alias); 18 May 2007 21:04:40 -0000 Received: (qmail 26009 invoked by alias); 18 May 2007 21:04:24 -0000 Date: Fri, 18 May 2007 21:04:00 -0000 Message-ID: <20070518210424.26008.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "gdr at cs dot tamu dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg01468.txt.bz2 ------- Comment #100 from gdr at cs dot tamu dot edu 2007-05-18 22:04 ------- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "ian at airs dot com" writes: | I'm not sure what to make of comment #84. We don't determine aliasing by | alignment or size. We determine it by type. We don't currently treat int and | long as aliasing each other even if they happen to have the same alignment and | size. That is GOOD. :-) | I believe this is correct according to the C standard but I am less | familiar with the C++ standard. It is also correct semantics with respect to C++. C++ goes further (I don't have C standard handy to check). The memory pointed to by p must have the "right" alignment requirements etc. So if you grab memory into p and it does not have the right alignment, then the new placement yields undefined behaviour. That is not a property we can check statically (until we get the alignment proposal into C++). | We could change the aliasing machinery in that | way for C++ if it seems to be appropriate, but I would prefer to take that to a | different PR. What I was trying to say was that C++ provides the same "dynamic type" (non-)aliasing guarantees, and goes even further. Did I manage to confuse you again? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286