From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20565 invoked by alias); 18 May 2011 17:21:17 -0000 Received: (qmail 20546 invoked by uid 22791); 18 May 2011 17:21:14 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ksp.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.206) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 May 2011 17:20:59 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 89CD2F0522; Wed, 18 May 2011 19:20:57 +0200 (CEST) Date: Wed, 18 May 2011 18:07:00 -0000 From: Jan Hubicka To: Richard Guenther Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH][?/n] LTO type merging cleanup Message-ID: <20110518172057.GI31449@atrey.karlin.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg01297.txt.bz2 > > We can end up with an infinite recursion as gimple_register_type > tries to register TYPE_MAIN_VARIANT first. This is because we > are being called from the LTO type-fixup code which walks the > type graph and adjusts types to their leaders. So we can > be called for type SCCs that are only partially fixed up yet > which means TYPE_MAIN_VARIANT might temporarily not honor > the invariant that the main variant of a main variant is itself. > Thus, simply avoid recursing more than once - we are sure that > we will be reaching at most type duplicates in further recursion. > > Bootstrap & regtest pending on x86_64-unknown-linux-gnu. With this funcion WPA stage passes with some improvements I repported to mozilla metabug. We now get ICE in ltrans: #0 gimple_register_type (t=0x0) at ../../gcc/gimple.c:4616 #1 0x00000000005a0fc9 in gimple_register_canonical_type (t=0x7fffe851f498) at ../../gcc/gimple.c:4890 #2 0x000000000048f14d in lto_ft_type (t=0x7fffe851f498) at ../../gcc/lto/lto.c:401 #3 lto_fixup_types (t=0x7fffe851f498) at ../../gcc/lto/lto.c:581 #4 0x000000000048f4a0 in uniquify_nodes (node=Unhandled dwarf expression opcode 0xf3 TYPE_MAIN_VARIANT is NULL. (gdb) up #1 0x00000000005a0fc9 in gimple_register_canonical_type (t=0x7fffe851f498) at ../../gcc/gimple.c:4890 4890 t = gimple_register_type (TYPE_MAIN_VARIANT (t)); (gdb) p debug_generic_stmt (t) struct _ffi_type $1 = void (gdb) p debug_tree (t) constant 192> unit size constant 24> align 64 symtab 0 alias set -1 structural equality fields unit size align 64 symtab 0 alias set -1 canonical type 0x7ffff7eca690 precision 64 min max pointer_to_this reference_to_this > used unsigned nonlocal DI file ctypes/libffi/include/ffi.h line 109 col 0 size unit size align 64 offset_align 128 offset bit offset context chain used unsigned nonlocal HI file ctypes/libffi/include/ffi.h line 110 col 0 size unit size align 16 offset_align 128 offset bit offset context chain >> chain > $2 = void Let me know if there is anything easy I could work out ;) I think the bug may be in the recursion guard. When you have cycle of length greater than 2 of MVs, you won't walk them all. Honza