From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23159 invoked by alias); 9 Oct 2006 08:22:33 -0000 Received: (qmail 23086 invoked by uid 48); 9 Oct 2006 08:22:21 -0000 Date: Mon, 09 Oct 2006 08:22:00 -0000 Message-ID: <20061009082221.23085.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/29286] [4.0/4.1/4.2 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: "rguenth at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-10/txt/msg00685.txt.bz2 List-Id: ------- Comment #23 from rguenth at gcc dot gnu dot org 2006-10-09 08:22 ------- One point to remember is that C does not allow re-using of storage with a different type (which is what PR29272 is about and why that testcase is invalid). The storage type is either the declared one or the one assigned by virtue of the first assignment (or memcpy). So, int i; float f; memcpy(&f, &i, sizeof(f)); is valid, it doesn't change fs dynamic type but assigns it the bit-pattern of i. What the C++ standard seems to imply is that the storage type of a bunch of memory (or an object with automatic storage) changes on "assignment". So, indeed for C++ re-ordering writes is not allowed, and escaping pointers must be assumed to change dynamic type. So for C++ and 4.2 the best solution looks like to disable type based aliasing completely. For C I'm not sure the behavior the standard mandates is very appealing - at least changing dynamic type via the use of memcpy should be allowed as a GCC extension (like we allow type-punning via the union trick). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286