From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26447 invoked by alias); 8 Apr 2011 15:04:27 -0000 Received: (qmail 26426 invoked by uid 22791); 8 Apr 2011 15:04:26 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Apr 2011 15:04:17 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p38F4HSE023812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 11:04:17 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p38F4GvU011653; Fri, 8 Apr 2011 11:04:17 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p38F4E5o029851; Fri, 8 Apr 2011 11:04:15 -0400 Message-ID: <4D9F23EE.4040100@redhat.com> Date: Fri, 08 Apr 2011 15:04:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Michael Matz CC: gcc-patches@gcc.gnu.org Subject: Re: Fix PR48389: ICE in make_edges References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-04/txt/msg00640.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/11 07:33, Michael Matz wrote: > Hi, > > the problem is that some initializers expand to loops. If such > initializers are inserted on edges we have looping control flow on them. > Even if we have no loops, but normal control flow on them (which can > happen in other situations) we still forget to initialize JUMP_LABEL on > them leading to potential problems downstream (no idea why we never hit > any real problems until we had loops on edges, this problem is latent > since expand from SSA form). > > So, we have to initialize the jump labels somewhen. The obvious idea to > simply call rebuild_jump_labels after all insertions are done doesn't > work, because the jump labels are already needed for splitting edges (for > patching the jump insns), which insertion might cause. > > So, instead than this I've added another interface to initialize jump > labels for a non-main chain of instructions (in fact it's the same as with > the main chain, merely not diddling with the forced_labels list). > > Fixes the testcase, gcc dg.exp is clean, I'm currently regstrapping this > on x86_64-linux. Okay if that passes? > > > Ciao, > Michael. > PR middle-end/48389 > * jump.c (rebuild_jump_labels_1, rebuild_jump_labels_chain): New > functions. > (rebuild_jump_labels): Call rebuild_jump_labels_1. > * rtl.h (rebuild_jump_labels_chain): Declare. > * cfgexpand.c (expand_gimple_basic_block): Use PAT_VAR_LOCATION_LOC, > not INSN_VAR_LOCATION_LOC. > (gimple_expand_cfg): Initialize JUMP_LABEL also on insn inserted > on edges. > > testsuite/ > * gcc.target/i386/pr48389.c: New test. I'd pondered a similar approach, but hadn't tried an implementation. Good to see it wasn't hard to make it work. I like this better than Steven's approach. OK by me. Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNnyPuAAoJEBRtltQi2kC7us4H/02MnP3HKapVMu/DoXAwyxBJ 6lN8xSdFY7Z/DQbHnU9SiKvB8UlcPQs1HHN4MiFrNZ23n0Qhtd4Z4bphbnzb2cXs gayymOheYGlEy7U/YHTUCjqOryMZbkwYybNbrFTlkl4d5Ymp2HEphZHn8G/8sRIr 9LY4o++M08zvZwX5WGd/NFJ9UosxCayhmfvA+raSwAuoz00EgD2Ns5KiqsLIhSey A9RxKkV2Czo2piqdO2wlv0NtVzQMAyDsDU5pv+1zec6Vf1UuuZzLslPGVdVyNQqk NCoz5gO8AyPLiMuNp57W0RtLtXHdwwGGVEv3y5AZ7T4bVvTVlAUuFhixeAc5tQ0= =jS34 -----END PGP SIGNATURE-----