From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14408 invoked by alias); 14 Dec 2010 13:42:02 -0000 Received: (qmail 14392 invoked by uid 22791); 14 Dec 2010 13:41:59 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 14 Dec 2010 13:41:52 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 14 Dec 2010 13:41:48 +0000 Received: from [10.1.67.34] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Dec 2010 13:41:46 +0000 Subject: Re: [ARM] Fix an internal error From: Richard Earnshaw To: Bernd Schmidt Cc: GCC Patches In-Reply-To: <4D06A565.4030103@codesourcery.com> References: <4D06A565.4030103@codesourcery.com> Date: Tue, 14 Dec 2010 14:05:00 -0000 Message-Id: <1292334106.13962.60.camel@e102346-lin.cambridge.arm.com> Mime-Version: 1.0 X-MC-Unique: 110121413414801801 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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: 2010-12/txt/msg01096.txt.bz2 On Mon, 2010-12-13 at 23:59 +0100, Bernd Schmidt wrote: > This fixes a crash while compiling a customer testcase (which I don't > know yet whether it can be posted) for ARM. Going into combine, we have >=20 > (insn 166 165 167 20 10208.c:22 (set (reg:CC 24 cc) > (compare:CC (reg:SI 141 [ D.2039 ]) > (const_int 78 [0x4e]))) >=20 > (insn 167 166 169 20 10208.c:22 (set (reg:SI 276) > (eq:SI (reg:CC 24 cc) > (const_int 0 [0x0]))) >=20 > (insn 169 167 170 20 10208.c:22 (set (reg:CC 24 cc) > (compare:CC (reg:SI 141 [ D.2039 ]) > (const_int 110 [0x6e]))) >=20 > (insn 170 169 172 20 10208.c:22 (set (reg:SI 278) > (eq:SI (reg:CC 24 cc) > (const_int 0 [0x0]))) >=20 > (insn 172 170 173 20 10208.c:22 (set (reg:SI 279) > (ior:SI (reg:SI 276) > (reg:SI 278))) >=20 > (insn 173 172 174 20 10208.c:14 (set (reg/v:SI 136 [ cur_k ]) > (and:SI (reg:SI 279) > (const_int 255 [0xff]))) >=20 > (insn 174 173 175 20 10208.c:28 (set (reg:CC 24 cc) > (compare:CC (reg/v:SI 136 [ cur_k ]) > (const_int 0 [0x0]))) >=20 > (jump_insn 175 174 192 20 10208.c:28 (set (pc) > (if_then_else (le (reg:CC 24 cc) > (const_int 0 [0x0])) > (label_ref 180) > (pc))) >=20 > All this gets combined so that we finally end up with the following > pattern, i3 =3D=3D insn 174: >=20 > (set (reg:CC 24 cc) > (compare:CC (ior:SI (eq:SI (reg:SI 141 [ D.2039 ]) > (const_int 78 [0x4e])) > (eq:SI (reg:SI 141 [ D.2039 ]) > (const_int 110 [0x6e]))) > (const_int 0 [0x0]))) >=20 > We call arm_select_cc_mode, it returns CC_DEQmode, and we later crash in > get_arm_condition_code because we don't expect to see a LE comparison > with that mode. >=20 > Fixed with the following patch. The comment at the top of > arm_select_dominance_cc_mode states that "in all cases OP will be EQ or > NE", which matches the assert in get_arm_condition_code, but the caller > does not ensure it. >=20 > This looks suspiciously like we have a missed-optimization bug as well, > but I did not investigate it. In the following gimple, the > compare-and-jump ought to be optimized away. >=20 Maybe not optimized away, but certainly simplified to an equality operation (> 0 is equivalent to !=3D 0 given the domain of the values assigned to cur_k_11). > D.2040_26 =3D D.2039_25 =3D=3D 110; > D.2041_27 =3D D.2039_25 =3D=3D 78; > D.2042_28 =3D D.2041_27 | D.2040_26; > cur_k_11 =3D (int) D.2042_28; > if (cur_k_11 > 0) > goto ; > else > goto ; >=20 > Ok? >=20 Yes. R.