From owner-freebsd-toolchain@FreeBSD.ORG Thu Jul 21 13:51:33 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B82106566B; Thu, 21 Jul 2011 13:51:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A96288FC17; Thu, 21 Jul 2011 13:51:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a] (unknown [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F0E225C37; Thu, 21 Jul 2011 15:51:31 +0200 (CEST) Message-ID: <4E282EE4.50500@FreeBSD.org> Date: Thu, 21 Jul 2011 15:51:32 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <201107211217.p6LCHV9p025307@fire.js.berklix.net> In-Reply-To: <201107211217.p6LCHV9p025307@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Julian H. Stacey" , freebsd-toolchain@freebsd.org, freebsd-i386@freebsd.org Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 13:51:34 -0000 On 2011-07-21 14:17, Julian H. Stacey wrote: > Summary: > I found a problem with CFLAGS += -march=i586 on an i686 linking > a crt.o for an i686, then not running on an i586, IMHO this is a bit of a PEBKAC issue. If you change CPUFLAGS to target a specific CPU, you should really rebuild all of world with it, not just a single program. In fact, you should rebuild all your ports too. > I suggested > maybe -march could be extended to also select seperate lib sub > directories to at least trigger a link failure, rather than a silent > apparent good compile of a bad binary. I think this would add a whole lot of complexity for very little gain, and still not save you from potential problems. You would really have to use the same approach for all system libraries, otherwise you might link in something from e.g. libc or libcrypto that was optimized for the wrong CPU. And I'm not even mentioning objects and/or libraries from ports... :) The compiler cannot automagically determine whether any object or library file you link into your program is fit to run on the CPU you are targeting, unless you would add information specifying the CPU type (and other particulars) to the object files themselves. In the end, it is up to you to make sure you do not mix "incompatible" object code. Having said all this, if you are worried particularly about the crt*.o files, then we could simply always build those with 'lowest common denominator' flags, like we do with e.g. the dynamic linker. I doubt very much that the startup code gains any performance by optimizing for higher CPU types.