From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EEC19138CC5 for ; Tue, 24 Mar 2015 00:37:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2C338E0929; Tue, 24 Mar 2015 00:37:36 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by pigeon.gentoo.org (Postfix) with ESMTP id 2C31DE084D for ; Tue, 24 Mar 2015 00:37:35 +0000 (UTC) Received: from [142.196.200.180] ([142.196.200.180:33761] helo=navi.localnet) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id AF/37-09217-EC1B0155; Tue, 24 Mar 2015 00:37:34 +0000 From: Fernando Rodriguez To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code? Date: Mon, 23 Mar 2015 20:37:02 -0400 Message-ID: <1714882.Lr3TaDaFxE@navi> User-Agent: KMail/4.14.3 (Linux/3.19.1; KDE/4.14.3; x86_64; ; ) In-Reply-To: References: <20150319015612.GA7416@waltdnes.org> <3086055.ZU6mplhdnj@navi> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-Archives-Salt: 70ed84a3-2546-46c9-b22a-0118e7b4b12e X-Archives-Hash: b38774bd5ee90a291cbbb5f499e22617 On Monday, March 23, 2015 6:48:39 PM Mike Gilbert wrote: > On Mon, Mar 23, 2015 at 6:41 PM, Fernando Rodriguez > wrote: > > On Monday, March 23, 2015 6:18:46 PM Mike Gilbert wrote: > >> On Mon, Mar 23, 2015 at 9:51 PM, Walter Dnes wrote: > >> > On Sun, Mar 22, 2015 at 09:25:53PM -0400, Fernando Rodriguez wrote > >> > > >> >> I guess gcc devs are careful when using the model numbers (Intel > >> >> lists 3 for Atoms, gcc uses only two so that may account for the > >> >> models I mentioned) but the chance of error is there. The -mno-xxx > >> >> flags would safeguard against it. > >> > > >> > I have one of the earliest Atom chips. Some people have a hard time > >> > believing this, but it's a 32-bit-only chip; a couple of lines from > >> > /proc/cpuinfo > >> > > >> > model name : Intel(R) Atom(TM) CPU Z520 @ 1.33GHz > >> > address sizes : 32 bits physical, 32 bits virtual > >> > > >> > Intel gives the CPU's specs at... > >> > > >> > http://ark.intel.com/products/35466/Intel-Atom-Processor-Z520-512K-Cache-1_33-GHz-533-MHz-FSB > >> > > >> > ...where it specifically says... > >> > > >> > Intel 64 # No > >> > > >> > I want to make absolutely certain that "illegal instructions" are not > >> > compiled for it. > >> > >> You will probably need to add -m32 to CFLAGS to avoid building 64-bit > >> objects on the 64-bit machine. > >> > > > > Your CPU is an example of what I'm saying, not just because it doesn't have 64 > > bit extensions but because it doesn't have MMX (at least according to the > > specs) and according to the GCC manual -march=atom means: "Intel Atom CPU with > > 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set > > support." So I guess it's more common than I thought. > > > > So you may also want to add -mno-mmx to be sure. GCC does check for mmx but it > > doesn't not use it on the output (probably a bug?). > > > > It's much more likely that Intel's website doesn't bother including > MMX because it is so damn old that nobody cares. > > /proc/cpuinfo would be a more reliable source of data. > I agree that's very likely, that's why I said if the specs are right... This one doesn't list any SIMD extensions at all: http://ark.intel.com/products/85475/Intel-Atom-x7-Z8700-Processor-2M-Cache-up-to-2_40-GHz -- Fernando Rodriguez