From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1308 invoked by alias); 10 Dec 2008 13:14:43 -0000 Received: (qmail 1048 invoked by uid 48); 10 Dec 2008 13:13:21 -0000 Date: Wed, 10 Dec 2008 13:14:00 -0000 Message-ID: <20081210131321.1046.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/38253] [4.4 regression] g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub 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: 2008-12/txt/msg01007.txt.bz2 ------- Comment #5 from jakub at gcc dot gnu dot org 2008-12-10 13:13 ------- I guess the primary difference between e.g. x86_64 or i386 and powerpc is during gimplification, the pointer-to-member initialization is done as: D.1804.__pfn = funcOne; D.1804.__delta = 0; i.1 = docalling (D.1804); on i386/x86_64, but as: static struct { String:: * __pfn; long int __delta; } C.1 = {.__pfn=funcOne, .__delta=0}; ... D.1807 = C.1; i.2 = docalling (D.1807); and later on esra even makes it harder to find out what the function is. This is gimplify_init_constructor, where: if (size > 0 && !can_move_by_pieces (size, align)) (for -m64 with size 16, align 64, for -m32 with size 8, align 32) on powerpc is true and so a temporary is created, on i386/x86_64 can_move_by_pieces returns 1 because MOVE_RATIO is larger and so it is initialized piece-wise. In this case (2 integral field ctor, one entry is 0, one is an address) I doubt it makes sense on any arch to do the temporary (if that would be true, then just the constant should be forced into memory by mov[sd]i expander). can_move_by_pieces doesn't make much sense either, we are deciding whether to initialize piece-wise or not, for piece-wise initialization we want to see if storing the constants into memory isn't too expensive (so more like can_store_by_pieces with appropriate callback). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38253