From owner-svn-src-all@FreeBSD.ORG Wed Jan 5 20:38:16 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3DF481065672; Wed, 5 Jan 2011 20:38:16 +0000 (UTC) Date: Wed, 5 Jan 2011 20:38:16 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110105203816.GA54929@freebsd.org> References: <201101042051.p04KpSGk054564@svn.freebsd.org> <20110105185944.GA30449@freebsd.org> <4D24CD98.9080906@FreeBSD.org> <201101051508.40337.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101051508.40337.jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Doug Barton , Dimitry Andric , src-committers@freebsd.org Subject: Re: svn commit: r216977 - in head/libexec/rtld-elf: amd64 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, 05 Jan 2011 20:38:16 -0000 On Wed Jan 5 11, John Baldwin wrote: > On Wednesday, January 05, 2011 2:59:20 pm Doug Barton wrote: > > 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. > > My suggestion was that we ask clang to add a '-mno-whatever' and hopefully we > could convince gcc to follow suit. clang developers seem to be fairly > receptive, so I was hoping one of our clang liaisons could suggest it. :) why gcc? even if they decide to add such a switch it will be gpl3'ed. shouldn't gcc with clang at hand be considered legacy software? cheers. alex ps: btw there is a patch in GNATS which bumps base gcc to the very last revision which didn't include gplv3. i think the patch fixes quite a few issues: 153298. also it seems apple is maintaining a gcc branch which has a lot of improvements, yet it is based on gcc 4.2.1 and thus licensed under gplv2. i'm not sure if it is avalable somewhere, but having a peek at the changes they made would in fact be nice. still i don't think tackling base gcc is worth the hassle, since that time could be spent much better improving clang. > > -- > John Baldwin -- a13x