From owner-freebsd-toolchain@FreeBSD.ORG Tue Feb 1 19:25:56 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 485A11065673; Tue, 1 Feb 2011 19:25:56 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E63168FC17; Tue, 1 Feb 2011 19:25:55 +0000 (UTC) Received: by yxh35 with SMTP id 35so2790139yxh.13 for ; Tue, 01 Feb 2011 11:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:cc:content-type; bh=raZsO2bCE6fwjeQiBzGJCcb8VF/GxUFwrJghOeyHZvI=; b=c/wmLI8duFvotSM284gEMmqr3DFElv5LnLVKGMPDNp3I7BBkdRnwnhXH5xwUN+clGD N8T9guRIv1Ek+UxI1wtU+qR5Q0SUavmK0/r8gq8qRB+IXGl87YoCuCvq+z6L8xnITZt/ svWn3lEx1hYN5VFwEcJ40iteYyXumMJRGeuvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=JtczVZdoyTn9u7B1UkgGJpxC6sm4lK6AI6Dw4Ky5ccqioY138H+pdbX6l4tTiNPjSV YJUKwHJoV/1I7hzbn/gv6WbHvhqNlGUvO9jeX4tvfWGb2m8w2FAM70hrW/Bxkz24r4xW JT2i6q0ZSzL3IX9yuGtpwkNoDHiyn3MAhF7Lw= MIME-Version: 1.0 Received: by 10.236.111.43 with SMTP id v31mr16750903yhg.23.1296588348730; Tue, 01 Feb 2011 11:25:48 -0800 (PST) Received: by 10.236.105.197 with HTTP; Tue, 1 Feb 2011 11:25:48 -0800 (PST) Date: Tue, 1 Feb 2011 14:25:48 -0500 Message-ID: From: "b. f." To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-toolchain@FreeBSD.org, gerald@FreeBSD.org Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:25:56 -0000 Warner Losh wrote: > On 02/01/2011 04:27, b. f. wrote: > > Gerald Pfeifer wrote: > >> On Sun, 30 Jan 2011, Alexander Best wrote: > >>> i might have described things a bit too complicated. basically i want to > >>> have CPUTYPE ?= core2 in my make.conf. clang is capable of producing > >>> core2 specific code, however core2 always gets downgraded by > >>> share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. > >>> > >>> any chance of fixing this? > >> I guess one of those extern compilers Robert has in mind should > >> be lang/gcc46 from the Ports Collection which is perfectly happy > >> to generate core2 code. I agree we need good infrastructure to > >> support such cases. > > > > Related: > > > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/84800 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/112997 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/30399 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/122623 > > > > The longevity of some of these is remarkable. > > Wow! I think the fortran one takes the cake for ancientness :) When > applying it, keep in mind that we do things a little differently... > Maybe I'll take a look at it/them :) I didn't mean to suggest that the proposals of the original submitters be adopted in each case above, just that the PRs ought to be resolved, as they have practical consequences for users. I had mentioned the Fortran PR earlier to the GCC ports maintainer, and he saw no reason why the default Fortran bits (default targets, compiler and flag definitions) couldn't be shifted from src/share/mk/sys.mk and src/share/mk/bsd.lib.mk to ports/Mk/bsd.gcc.mk and placed under the USE_FORTRAN knob, as they are no longer used in the base system, and applicable standards like: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html state that " Implementations that do not support FORTRAN may omit FC, FFLAGS, and the .f inference rules." This would allow the ports committers to more easily maintain those bits, and the few users who rely on those bits for software that is not in either Ports or the base system could probably easily adapt to such a change. But even if such a change isn't adopted, the default FFLAGS probably ought to be set to be the same as the default CFLAGS, including the option to specify -mtune=... That would simplify matters, and I think at the moment that they are too conservative. While we are on the topic, in reference to my earlier comment in conf/112997, is anyone working on adding basic OS support for some of the newer CPU instruction sets to FreeBSD? Even if we can't use them with the older base system compiler, I think that a growing number of users would like to use them with clang or the other newer compilers in Ports. b.