From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5101 invoked by alias); 10 Aug 2010 16:48:43 -0000 Received: (qmail 5087 invoked by uid 22791); 10 Aug 2010 16:48:41 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_05,MSGID_MULTIPLE_AT,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (217.140.96.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Aug 2010 16:48:31 +0000 Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id o7AGltF9010087 for ; Tue, 10 Aug 2010 17:47:55 +0100 (BST) Received: from E102352 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2010 17:48:28 +0100 From: "Ian Bolton" To: Subject: Question about tree-switch-conversion.c Date: Tue, 10 Aug 2010 22:58:00 -0000 Message-ID: <000401cb38ab$da1fa0a0$8e5ee1e0$@Bolton@arm.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01CB38B4.3BE408A0" x-cr-hashedpuzzle: BGmU BxME CPda CRAI CU9c CYZj Cikr EUEn FLKa GIC6 GSJi GnFJ G9mC IF+W IKw7 I4oE;1;ZwBjAGMAQABnAGMAYwAuAGcAbgB1AC4AbwByAGcA;Sosha1_v1;7;{DA3A916F-E06D-4498-8EB1-A4B93C508BED};aQBhAG4ALgBiAG8AbAB0AG8AbgBAAGEAcgBtAC4AYwBvAG0A;Tue, 10 Aug 2010 16:48:21 GMT;UQB1AGUAcwB0AGkAbwBuACAAYQBiAG8AdQB0ACAAdAByAGUAZQAtAHMAdwBpAHQAYwBoAC0AYwBvAG4AdgBlAHIAcwBpAG8AbgAuAGMA x-cr-puzzleid: {DA3A916F-E06D-4498-8EB1-A4B93C508BED} X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00177.txt.bz2 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01CB38B4.3BE408A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-length: 1697 I am in the process of fixing PR44328 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328) The problem is that gen_inbound_check in tree-switch-conversion.c subtracts info.range_min from info.index_expr, which can cause the MIN and MAX values for info.index_expr to become invalid. For example: typedef enum { FIRST = 0, SECOND, THIRD, FOURTH } ExampleEnum; int dummy (const ExampleEnum e) { int mode = 0; switch (e) { case SECOND: mode = 20; break; case THIRD: mode = 30; break; case FOURTH: mode = 40; break; } return mode; } tree-switch-conversion would like to create a lookup table for this, so that SECOND maps to entry 0, THIRD maps to entry 1 and FOURTH maps to entry 2. It achieves this by subtracting SECOND from index_expr. The problem is that after the subtraction, the type of the result can have a value outside the range 0-3. Later, when tree-vrp.c sees the inbound check as being <= 2 with a possible range for the type as 0-3, it converts the <=2 into a != 3, which is totally wrong. If e==FIRST, then we can end up looking for entry 255 in the lookup table! I think the solution is to update the type of the result of the subtraction to show that it is no longer in the range 0-3, but I have had trouble implementing this. The attached patch (based off 4.5 branch) shows my current approach, but I ran into LTO issues: lto1: internal compiler error: in lto_get_pickled_tree, at lto-streamer-in.c I am guessing this is because the debug info for the type does not match the new range I have set for it. Is there a *right* way to update the range such that LTO doesn't get unhappy? (Maybe a cast with fold_convert_loc would be right?) ------=_NextPart_000_0005_01CB38B4.3BE408A0 Content-Type: application/octet-stream; name="pr44328.gcc4.5.fix.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pr44328.gcc4.5.fix.patch" Content-length: 1422 Index: gcc/tree-switch-conversion.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- gcc/tree-switch-conversion.c (revision 162573)=0A= +++ gcc/tree-switch-conversion.c (working copy)=0A= @@ -721,6 +721,21 @@=0A= =20=0A= bound =3D fold_convert_loc (loc, utype, info.range_size);=0A= cond_stmt =3D gimple_build_cond (LE_EXPR, tmp_u_2, bound, NULL_TREE, NUL= L_TREE);=0A= +=0A= + /* Check that the subtraction does not cause underflow - if it does then= we=0A= + must fix up the max value for the tmp_u expression used in the cond_s= tmt,=0A= + so that simplify_cond_using_ranges() in tree-vrp.c has the correct va= lue=0A= + ranges to play with. */=0A= + if ((TREE_INT_CST_LOW(TYPE_MIN_VALUE (TREE_TYPE(tmp_u_2)))=0A= + - TREE_INT_CST_LOW(ulb))=0A= + > TREE_INT_CST_LOW(TYPE_MIN_VALUE (TREE_TYPE(tmp_u_2))))=0A= + {=0A= + TYPE_MAX_VALUE (TREE_TYPE (gimple_cond_lhs(cond_stmt)))=0A= + =3D build_int_cst (TREE_TYPE(gimple_cond_lhs(cond_stmt)),=0A= + TREE_INT_CST_LOW(TYPE_MIN_VALUE (TREE_TYPE(tmp_u_= 2)))=0A= + - TREE_INT_CST_LOW(ulb));=20=0A= + }=0A= +=0A= gsi_insert_before (&gsi, cond_stmt, GSI_SAME_STMT);=0A= update_stmt (cond_stmt);=0A= =20=0A= ------=_NextPart_000_0005_01CB38B4.3BE408A0--