From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20190 invoked by alias); 3 Feb 2010 21:44:43 -0000 Received: (qmail 20157 invoked by uid 48); 3 Feb 2010 21:44:33 -0000 Date: Wed, 03 Feb 2010 21:44:00 -0000 Message-ID: <20100203214433.20156.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call. In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "davidxl at gcc dot gnu dot org" 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: 2010-02/txt/msg00229.txt.bz2 ------- Comment #8 from davidxl at gcc dot gnu dot org 2010-02-03 21:44 ------- (In reply to comment #7) > It is valid to use placement new to construct a more or less derived type > which would change the vtable pointer. > > Thus I think this bug is still invalid. > How did you reach this conclusion from reading p7 of 3.8 in the standard? "The original object was a most derived object of type T and the new object is a most derived object of type T...." The following is allowed: class B { virtual ... }; class D : public B { ... }; B* bp = new D (); ... new (bp) D(); but vptr does not change. Set aside the standard -- this optimization is useful regardless. Some of the develpoers are so desperate that they manually do LICM of vptr and vtbl access for vcalls in the loop. The worst case is to use a option to guard it (which I think the default should be on). David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560