From owner-svn-src-head@FreeBSD.ORG Wed Jan 5 19:59:24 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14441065679 for ; Wed, 5 Jan 2011 19:59:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB348FC2A for ; Wed, 5 Jan 2011 19:59:23 +0000 (UTC) Received: (qmail 2844 invoked by uid 399); 5 Jan 2011 19:59:21 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Jan 2011 19:59:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D24CD98.9080906@FreeBSD.org> Date: Wed, 05 Jan 2011 11:59:20 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Best References: <201101042051.p04KpSGk054564@svn.freebsd.org> <20110105011635.GA4952@freebsd.org> <4D246444.1060904@FreeBSD.org> <20110105185944.GA30449@freebsd.org> In-Reply-To: <20110105185944.GA30449@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric Subject: Re: svn commit: r216977 - in head/libexec/rtld-elf: amd64 i386 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:59:24 -0000 On 01/05/2011 10:59, Alexander Best wrote: > judging from the discussion going on right now it seems those flags will be > grouped together to form a new variable. so things will probably change shortly > and fixing the order is probably not necessary. Much better to fix the problem properly now than to rely on future work that may or may not happen. I realize that you alluded to this later in your message, but I think as a general principle this is worth reinforcing. > some people have proposed hacking into clang which i personally think is a very > bad idea. why not contact the clang developers? they might like the idea of a > switch disabling all advanced extensions for every architecture? I agree with this. We have a very awkward situation right now with lots of local hacks in our version of gcc that in an ideal world we would not replicate with clang; particularly considering the much lower barrier to entry when it comes to contributing things back. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/