From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17845 invoked by alias); 3 Apr 2012 19:21:09 -0000 Received: (qmail 17836 invoked by uid 22791); 3 Apr 2012 19:21:07 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Apr 2012 19:20:51 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SF9HU-000149-2u from Maxim_Kuvyrkov@mentor.com ; Tue, 03 Apr 2012 12:20:40 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 12:20:34 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 3 Apr 2012 20:20:32 +0100 Subject: Re: [GCC Steering Committee] Android sub-port reviewer MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="us-ascii" From: Maxim Kuvyrkov In-Reply-To: <7C6479EB2BF52547AC332FD6034646DA01448C3AEF@exchdb03.mips.com> Date: Tue, 03 Apr 2012 19:21:00 -0000 CC: Andrew Pinski , Richard Sandiford , "gcc@gcc.gnu.org" Content-Transfer-Encoding: quoted-printable Message-ID: References: <16285357-1E07-4D60-BD8D-2B2FE796609B@codesourcery.com> <87sjgmm0rt.fsf@talisman.home> <7C6479EB2BF52547AC332FD6034646DA01448C282D@exchdb03.mips.com> <7C6479EB2BF52547AC332FD6034646DA01448C3ABE@exchdb03.mips.com> <7C6479EB2BF52547AC332FD6034646DA01448C3AEF@exchdb03.mips.com> To: "Fu, Chao-Ying" 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: 2012-04/txt/msg00060.txt.bz2 On 4/04/2012, at 6:28 AM, Fu, Chao-Ying wrote: > Andrew Pinski wrote: >> The point is mips*-*-* is big endian and mipsel*-*-* is little endian. >> And doing adding a target which says mips-linux-android which is >> little-endian is just backwards. Is there anyway to fix the target >> triplet to be mipsel-linux-android including inside the official NDK? >> If not then we have a broken triplet for android. >=20 > I agree with what you said. >=20 > The simplest fix is that mips-linux-android still generates big-endian c= ode > as the MIPS target triplet design. Don't ever set it to generate little-= endian code automatically. > For MIPS GCC Android patches to merge to FSF GCC trunk, we will never cha= nge endiannes. >=20 > Note that we did use a regular mips-linux-gnu GCC to compile Android sys= tems by using -EL. > The target of "mips-linux-android" is just invented to work with NDK scri= pts. > And people can freely create "mipsel-linux-*" toolchains to compile Andro= id systems directly, > or create "mips-linux-*" toolchains to compile Android systems with -EL. >=20 > The MIPS NDK script patch was just merged to googlesource last night. > I can work on another patch to use -EL options, but to let > "mips-linux-andoird" generate big-endian code. Is this solution ok for y= ou? I encourage you to submit the MIPS Android patches to gcc-patches@. And, a= s long as your changes preserve the status quo of mips-*-* being big-endian= by default and mipsel-*-* being little-endian by default, there should be = no major obstacles to merge those in. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics