From owner-svn-src-all@FreeBSD.ORG Wed May 30 09:00:24 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41479106572B; Wed, 30 May 2012 09:00:24 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id B56A28FC0A; Wed, 30 May 2012 09:00:17 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust790.5-4.cable.virginmedia.com [86.26.15.23]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q4U905kc009964 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 09:00:06 GMT (envelope-from theraven@theravensnest.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120530080151.GX90133@alchemy.franken.de> Date: Wed, 30 May 2012 10:00:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15CED26F-127B-4736-9E96-6315D6303B31@theravensnest.org> References: <201205270527.q4R5Rm44028055@svn.freebsd.org> <20120528190355.GA42283@alchemy.franken.de> <20120528204728.GD2358@deviant.kiev.zoral.com.ua> <20120529224833.GW90133@alchemy.franken.de> <20120530034747.GJ2358@deviant.kiev.zoral.com.ua> <20120530080151.GX90133@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1257) Cc: Konstantin Belousov , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r236137 - head/contrib/gcc/config/i386 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 09:00:24 -0000 On 30 May 2012, at 09:01, Marius Strobl wrote: > Ehm, yes, but given that this wouldn't be the first such flag we have > is avoiding it really worth the link time and run time overheads in > the long term?=20 Given the small overhead of the extra hashes, yes. At some point in the = future, we can turn off the older ones and get a tiny reduction in = overhead, but doing it now would cause much more pain for users in not = being able to copy binaries from slightly newer to slightly older = machines than we'd save from a tiny increase in binary size. This is the archetypal change for incremental deployment, let's not make = our users' lives difficult just because we can. David Who doesn't want to be woken up by mobs of users with flaming torches = and pitchforks.=