From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27207 invoked by alias); 9 May 2014 10:40:08 -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 27161 invoked by uid 89); 9 May 2014 10:40:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,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.89.28.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 May 2014 10:40:07 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 85FBAA9A6EF24; Fri, 9 May 2014 11:40:01 +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.181.6; Fri, 9 May 2014 11:40:03 +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.0174.001; Fri, 9 May 2014 11:40:02 +0100 From: Andrew Bennett To: Richard Sandiford CC: "gcc-patches@gcc.gnu.org" , Matthew Fortune , Saeed Ghazanfar , Rich Fuhler Subject: RE: [PATCH] Add support for MIPS r3 and r5 Date: Fri, 09 May 2014 10:40:00 -0000 Message-ID: <0DA23CC379F5F945ACB41CF394B982775792ED@LEMAIL01.le.imgtec.org> References: <0DA23CC379F5F945ACB41CF394B98277578C80@LEMAIL01.le.imgtec.org> <87mwes2hqe.fsf@talisman.default> In-Reply-To: <87mwes2hqe.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00582.txt.bz2 > -----Original Message----- > From: Richard Sandiford [mailto:rdsandiford@googlemail.com] > Sent: 08 May 2014 20:28 > To: Andrew Bennett > Cc: gcc-patches@gcc.gnu.org; Matthew Fortune; Saeed Ghazanfar; Rich Fuhler > Subject: Re: [PATCH] Add support for MIPS r3 and r5 >=20 > Andrew Bennett writes: > > diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.= def > > index 07fbf9c..f2e23c6 100644 > > --- a/gcc/config/mips/mips-cpus.def > > +++ b/gcc/config/mips/mips-cpus.def > > @@ -44,9 +44,13 @@ MIPS_CPU ("mips4", PROCESSOR_R8000, 4, 0) > > isn't tuned to a specific processor. */ > > MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY) > > MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, 33, PTF_AVOID_BRANCHLIKELY) > > +MIPS_CPU ("mips32r3", PROCESSOR_M4K, 34, PTF_AVOID_BRANCHLIKELY) > > +MIPS_CPU ("mips32r5", PROCESSOR_74KF2_1, 36, PTF_AVOID_BRANCHLIKELY) >=20 > Looks odd for mips32r2 and mips32r5 to have the same processor tuning > but mips32r3 to be different. I assume 74KF2_1 is just a reasonable > default, given the lack of tuning for a real r5 CPU? That's fine if so, > but probably deserves a comment. mips32r3 is basically micromips, so I have just used the same processor=20 definition that the micromips entry uses. On the processor for mips32r5 we should probably think of adding a processor definition for the P5600,=20 but using 74KF2_1 for the moment will be fine (and I will add a comment=20 to explain this). =20 > > @@ -141,7 +151,8 @@ along with GCC; see the file COPYING3. If not see > > "%{EL:-m elf32lmip} \ > > %{EB:-m elf32bmip} \ > > %(endian_spec) \ > > - %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips32r2} > %{mips64} \ > > + %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips32r2} > \ > > + %{mips32r3} %{mips32r5} %{mips64} \ > > %(netbsd_link_spec)" > > > > #define NETBSD_ENTRY_POINT "__start" >=20 > Not sure the omission of mips64r2 was deliberate here, or in vxworks.h. Yes it was deliberate: mips64r2 was already missing from the original ASM_S= PEC=20 in vxworks.h and the LINK_SPEC in netbsfd.h.=20=20 >=20 > As Joseph said, the .po stuff should be left alone. The .pot file is > regenerated near to a release so that the translators can update the > .po files. Thats fine, (and many thanks for both of you for clarifying this). I will= =20 remove the changes from the patch. > Looks good otherwise, thanks. I will prepare the revised patch, and will commit it once the copyright=20 assignment issues have been resolved. =20 Many thanks, Andrew