From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110129 invoked by alias); 14 Jul 2015 13:23:37 -0000 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 Received: (qmail 110116 invoked by uid 89); 14 Jul 2015 13:23:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Jul 2015 13:23:34 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 713EDE1B0DABB; Tue, 14 Jul 2015 14:23:29 +0100 (IST) Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Jul 2015 14:23:32 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0210.002; Tue, 14 Jul 2015 14:23:31 +0100 From: Andrew Bennett To: Richard Sandiford , Matthew Fortune CC: "gcc-patches@gcc.gnu.org" , "Moore, Catherine (Catherine_Moore@mentor.com)" Subject: RE: [PATCH] MIPS: Correctly update the isa and arch_test_option_p variables after the arch dependency handling code in mips.exp Date: Tue, 14 Jul 2015 13:23:00 -0000 Message-ID: <0DA23CC379F5F945ACB41CF394B98277210F525A@LEMAIL01.le.imgtec.org> References: <0DA23CC379F5F945ACB41CF394B98277210F39A7@LEMAIL01.le.imgtec.org> <6D39441BF12EF246A7ABCE6654B02353211CA8BD@LEMAIL01.le.imgtec.org> <87y4il311p.fsf@googlemail.com> In-Reply-To: <87y4il311p.fsf@googlemail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg01153.txt.bz2 > Yeah, I agree that this doesn't really fit the model that well, > but like you say, we're stretching the logic a bit :-). When I wrote it, > the architectures formed a nice tree in which moving to leaf nodes only > added features. So in the pre-r6 days: >=20 > # Handle dependencies between the pre-arch options and the arch optio= n. > # This should mirror the arch and post-arch code below. > if { !$arch_test_option_p } { >=20 > increased the architecture from the --target_board default to match > the features required by the test, whereas: >=20 > # Handle dependencies between the arch option and the post-arch optio= ns. > # This should mirror the arch and pre-arch code above. > if { $arch_test_option_p } { >=20 > turned off features from the --target_board default to match a lower > architecture required by the test. So in the pre-r6 days, all the code > in the second block was turning something off when going to a lower > architecture. The blocks were mutually-exclusive and writing it this > way reduced the number of redundant options. (Admittedly you could argue > that it's daft to worry about that given the kind of command lines you > tend to get from the rest of mips.exp. :-)) >=20 > r6 is the first time we've had to turn something off when moving up. > -mnan and -mabs are also the first options where old architectures > support only A, higher revisions support A and B, and the newest > revision supports only B. I think I'd prefer to acknowledge that > and have: >=20 > # Handle dependencies between the arch option and the post-arch optio= ns. > # This should mirror the arch and pre-arch code above. For pre-r6 > # architectures this only needs to be done when we've moved down > # to a lower architecture and might need to turn features off, > # but moving up from pre-r6 to r6 can remove features too. > if { $arch_test_option_p || ($orig_isa_rev < 6 && $isa_rev >=3D 6) } { >=20 > I think the existing r6->r5 case really is different: there we're > forcing a -mnan option not because the architecture needs it but > because the environment might. Hi, An updated patch and ChangeLog which reflects the comments is below. I have tested it on the mips-img-elf and mips-mti-elf toolchains with all the valid multilib configurations and there are no new regressions. Ok to commit? Regards, Andrew testsuite/ * gcc.target/mips/mips.exp (mips-dg-options): Allow the post-arch code to be run when the pre-arch code increases the isa_rev to=20 mips32r6 or greater.=20 diff --git a/gcc/testsuite/gcc.target/mips/mips.exp b/gcc/testsuite/gcc.tar= get/mips/mips.exp index 1dd4173..b3617e4 100644 --- a/gcc/testsuite/gcc.target/mips/mips.exp +++ b/gcc/testsuite/gcc.target/mips/mips.exp @@ -1045,6 +1045,7 @@ proc mips-dg-options { args } { set arch [mips_option options arch] set isa [mips_arch_info $arch isa] set isa_rev [mips_arch_info $arch isa_rev] + set orig_isa_rev $isa_rev =20 # If the test forces a 32-bit architecture, force -mgp32. # Force the current -mgp setting otherwise; if we don't, @@ -1279,8 +1280,11 @@ proc mips-dg-options { args } { } =20 # Handle dependencies between the arch option and the post-arch option= s. - # This should mirror the arch and pre-arch code above. - if { $arch_test_option_p } { + # This should mirror the arch and pre-arch code above. For pre-r6 + # architectures this only needs to be done when we've moved down + # to a lower architecture and might need to turn features off, + # but moving up from pre-r6 to r6 can remove features too. + if { $arch_test_option_p || ($orig_isa_rev < 6 && $isa_rev >=3D 6) } { if { $isa < 2 } { mips_make_test_option options "-mno-branch-likely" mips_make_test_option options "-mno-fix-r10000"