From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 07:13:18 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 888633DC; Sun, 25 Aug 2013 07:13:18 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4532CE0; Sun, 25 Aug 2013 07:13:18 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94] (unknown [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 4CBDB39821; Sun, 25 Aug 2013 00:13:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Rui Paulo In-Reply-To: <20130824230615.GA55855@troutmask.apl.washington.edu> Date: Sun, 25 Aug 2013 00:13:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , toolchain@freebsd.org, Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:13:18 -0000 On 24 Aug 2013, at 16:06, Steve Kargl = wrote: > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: >>=20 >>> And i found PR about clang and mplayer: ports/176272 >>> This PR contains log with build error log. >>=20 >> Please file clang bugs at http://llvm.org/bugs/ >>=20 >=20 > As if this is going to help. >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D8532 >=20 > 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same = problem. -- Rui Paulo From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 07:22:19 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54DC9764; Sun, 25 Aug 2013 07:22:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA252D6B; Sun, 25 Aug 2013 07:22:18 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDUgS-00050u-FN; Sun, 25 Aug 2013 11:24:24 +0400 Date: Sun, 25 Aug 2013 11:24:24 +0400 From: Slawa Olhovchenkov To: Rui Paulo Subject: Re: GCC withdraw Message-ID: <20130825072424.GI3796@zxy.spb.ru> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current , toolchain@freebsd.org, Steve Kargl , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:22:19 -0000 On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: > On 24 Aug 2013, at 16:06, Steve Kargl wrote: > > > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >> > >>> And i found PR about clang and mplayer: ports/176272 > >>> This PR contains log with build error log. > >> > >> Please file clang bugs at http://llvm.org/bugs/ > >> > > > > As if this is going to help. > > > > http://llvm.org/bugs/show_bug.cgi?id=8532 > > > > 2 years, 9 month and counting. > > > Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 07:23:53 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B60558B1; Sun, 25 Aug 2013 07:23:53 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8B42D8B; Sun, 25 Aug 2013 07:23:53 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94] (unknown [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id EDFED39821; Sun, 25 Aug 2013 00:23:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Rui Paulo In-Reply-To: <20130825072424.GI3796@zxy.spb.ru> Date: Sun, 25 Aug 2013 00:23:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E8FB8C9-F685-43E5-B810-B2609E679273@FreeBSD.org> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> <20130825072424.GI3796@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , toolchain@freebsd.org, Steve Kargl , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:23:53 -0000 On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote: > On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: >=20 >> On 24 Aug 2013, at 16:06, Steve Kargl = wrote: >>=20 >>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >>>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov = wrote: >>>>=20 >>>>> And i found PR about clang and mplayer: ports/176272 >>>>> This PR contains log with build error log. >>>>=20 >>>> Please file clang bugs at http://llvm.org/bugs/ >>>>=20 >>>=20 >>> As if this is going to help. >>>=20 >>> http://llvm.org/bugs/show_bug.cgi?id=3D8532 >>>=20 >>> 2 years, 9 month and counting. >>=20 >>=20 >> Irrelevant to the discussion since the base system GCC has the same = problem. >=20 > How about ports/180564? > And llvm community known about this issue: > = http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.htm= l Have you tried submitting that directly to mplayer? -- Rui Paulo From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 07:23:56 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19F809AB; Sun, 25 Aug 2013 07:23:56 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0A822D8C; Sun, 25 Aug 2013 07:23:55 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so3319081ieb.17 for ; Sun, 25 Aug 2013 00:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I8G1C6xISk0AUk1/Bmr3Y0TMAe5jRZqqdrIiW4aQqLc=; b=Nyk8rxTRem1V3X0I4i9paouR3ecBiEVy766M7lVxGdCulSkE/rJX82TACbn603oDYp stnLDhnesGnBIXEfl140/k+RHTE3A+BUftZjHUN3NyBZC098bEp46K92WQ/MIsPAoGlb YM5PDrV7J1pGFLIGpuVvbWimheWM6djIfMm0mHj1QNjSf5M46yOuEtOa0G5SQMX4RSHJ tCyR4juv/w8CkaaRXbBTbjRll5ZT4XqD9QlV8zP7lCTd9P26ecLUy4Ufx/Qhb+AlTNwr ezPKb8XKnafYrYlE6we2agGLCKXZ2bFe4XRY5Mv1x81DvXYJAeoZcTcjttdsjHmzmb6j XaMQ== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr3071505igb.38.1377415435034; Sun, 25 Aug 2013 00:23:55 -0700 (PDT) Received: by 10.50.209.38 with HTTP; Sun, 25 Aug 2013 00:23:54 -0700 (PDT) In-Reply-To: <20130824224204.GH3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> Date: Sun, 25 Aug 2013 02:23:54 -0500 Message-ID: Subject: Re: GCC withdraw From: Scot Hetzel To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:23:56 -0000 On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote: > On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: > >> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: >> >> > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: >> > >> > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang >> > > don't understand inlined asm. >> > >> > Clang supports inline asm. If there is some specific inline asm >> > syntax that clang does not recognise, then please will you point me >> > to the relevant LLVM bug report and I will investigate it. >> >> Sorry, I don't know about clang/llvm bug reports, I just try to build >> mplayer with Win32 codecs support on FreeBSD-10/i386. >> >> And currenly (in rev r315041) building by clang disabled in ports tree. > > And i found PR about clang and mplayer: ports/176272 > This PR contains log with build error log. PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the issue was fixed by updating the port to a more recent version. Mplayer is currently mplayer-1.1.r20130308, do you still see the same issues with clang? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 07:51:05 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DA11DD9; Sun, 25 Aug 2013 07:51:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 16D852EB4; Sun, 25 Aug 2013 07:51:05 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDV8J-0005SZ-3n; Sun, 25 Aug 2013 11:53:11 +0400 Date: Sun, 25 Aug 2013 11:53:11 +0400 From: Slawa Olhovchenkov To: Scot Hetzel Subject: Re: GCC withdraw Message-ID: <20130825075311.GJ3796@zxy.spb.ru> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:51:05 -0000 On Sun, Aug 25, 2013 at 02:23:54AM -0500, Scot Hetzel wrote: > On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote: > > On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: > > > >> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: > >> > >> > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: > >> > > >> > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > >> > > don't understand inlined asm. > >> > > >> > Clang supports inline asm. If there is some specific inline asm > >> > syntax that clang does not recognise, then please will you point me > >> > to the relevant LLVM bug report and I will investigate it. > >> > >> Sorry, I don't know about clang/llvm bug reports, I just try to build > >> mplayer with Win32 codecs support on FreeBSD-10/i386. > >> > >> And currenly (in rev r315041) building by clang disabled in ports tree. > > > > And i found PR about clang and mplayer: ports/176272 > > This PR contains log with build error log. > > PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the > issue was fixed by updating the port to a more recent version. > > Mplayer is currently mplayer-1.1.r20130308, do you still see the same > issues with clang? Now issues as in ports/180564. Not same, but very close ('ran out of registers during register allocation' in other place). From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 07:52:19 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9440FF11; Sun, 25 Aug 2013 07:52:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6ED2EC5; Sun, 25 Aug 2013 07:52:19 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDV9U-0005Ui-Tj; Sun, 25 Aug 2013 11:54:24 +0400 Date: Sun, 25 Aug 2013 11:54:24 +0400 From: Slawa Olhovchenkov To: Rui Paulo Subject: Re: GCC withdraw Message-ID: <20130825075424.GK3796@zxy.spb.ru> References: <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> <20130825072424.GI3796@zxy.spb.ru> <4E8FB8C9-F685-43E5-B810-B2609E679273@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8FB8C9-F685-43E5-B810-B2609E679273@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current , toolchain@freebsd.org, Steve Kargl , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:52:19 -0000 On Sun, Aug 25, 2013 at 12:23:45AM -0700, Rui Paulo wrote: > On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote: > > > On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: > > > >> On 24 Aug 2013, at 16:06, Steve Kargl wrote: > >> > >>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >>>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >>>> > >>>>> And i found PR about clang and mplayer: ports/176272 > >>>>> This PR contains log with build error log. > >>>> > >>>> Please file clang bugs at http://llvm.org/bugs/ > >>>> > >>> > >>> As if this is going to help. > >>> > >>> http://llvm.org/bugs/show_bug.cgi?id=8532 > >>> > >>> 2 years, 9 month and counting. > >> > >> > >> Irrelevant to the discussion since the base system GCC has the same problem. > > > > How about ports/180564? > > And llvm community known about this issue: > > http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html > > > Have you tried submitting that directly to mplayer? No, I don't know about mplayer bug database and mplayer's support FreeBSD-current as target. From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 10:09:16 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D5D166B; Sun, 25 Aug 2013 10:09:16 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18F65251D; Sun, 25 Aug 2013 10:09:15 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7PA92QG021103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 Aug 2013 10:09:03 GMT (envelope-from theraven@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <20130824230615.GA55855@troutmask.apl.washington.edu> Date: Sun, 25 Aug 2013 11:08:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 10:09:16 -0000 On 25 Aug 2013, at 00:06, Steve Kargl = wrote: > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: >>=20 >>> And i found PR about clang and mplayer: ports/176272 >>> This PR contains log with build error log. >>=20 >> Please file clang bugs at http://llvm.org/bugs/ >>=20 >=20 > As if this is going to help. >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D8532 >=20 > 2 years, 9 month and counting. This bug relates to a corner case in complex floating point support, = which GCC in base doesn't get right either, and which affects a tiny = proportion of users and which comes with a hypothetical test case but no = evidence that any real-world code is affected by it. If you have some = real-world code that is compiled correctly by GCC but incorrectly by = clang as a result of this, then please update the bug. Oh, and it's worth noting that clang, as an extension, supports using = initialiser lists to create complex values and so this particular case = is trivial to avoid if you use this feature, which you will if you = create complex numbers using the macro that the C specification = introduced specifically to avoid this case. =20 David From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 14:21:15 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67B75A0C; Sun, 25 Aug 2013 14:21:15 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37AFC2FF1; Sun, 25 Aug 2013 14:21:15 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VDbBp-000OyN-U0; Sun, 25 Aug 2013 14:21:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7PEL9v9050618; Sun, 25 Aug 2013 08:21:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/1Gz/VK1ocXq4RluFl/ePH Subject: Re: GCC withdraw From: Ian Lepore To: David Chisnall In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Aug 2013 08:21:09 -0600 Message-ID: <1377440469.1111.124.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 14:21:15 -0000 On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote: > On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > > > And i found PR about clang and mplayer: ports/176272 > > This PR contains log with build error log. > > Please file clang bugs at http://llvm.org/bugs/ > > David > And THIS is a major reason why FreeBSD needs a compiler in base instead of all tools being ports. The last thing we need is to start responding to every problem with "this is not my problem, go file a report upstream." If we're already doing it for the compiler that's supposed to be the new supported tool, how much worse will peoples' experience be when we assert no ownership or responsibility for a toolchain at all? -- Ian From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 15:30:36 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF2D7C9F; Sun, 25 Aug 2013 15:30:36 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 681532363; Sun, 25 Aug 2013 15:30:36 +0000 (UTC) Received: from [192.168.1.69] (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id A575310947; Sun, 25 Aug 2013 15:24:23 +0000 (UTC) Received: from [192.168.1.69] ([UNAVAILABLE]. [176.222.238.90]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/4.8.87); Sun, 25 Aug 2013 15:16:42 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Erik Cederstrand In-Reply-To: <1377440469.1111.124.camel@revolution.hippie.lan> Date: Sun, 25 Aug 2013 17:24:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <1377440469.1111.124.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , toolchain@FreeBSD.org, Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 15:30:36 -0000 Den 25/08/2013 kl. 16.21 skrev Ian Lepore : >> Please file clang bugs at http://llvm.org/bugs/ >=20 > And THIS is a major reason why FreeBSD needs a compiler in base = instead > of all tools being ports. The last thing we need is to start = responding > to every problem with "this is not my problem, go file a report > upstream." If we're already doing it for the compiler that's supposed > to be the new supported tool, how much worse will peoples' experience = be > when we assert no ownership or responsibility for a toolchain at all? I think it's perfectly reasonable to direct compilation problems in a = program residing in ports to the developers of the compiler. It really = has nothing to do with the FreeBSD base compiler. The reason being that = mplayer relies on a non-docmented GCC-specific asm side-effect, and = there's a one-line patch in the PR which solves the problem, makes the = claim even more absurd. Expecting FreeBSD Clang maintainers to respond to compilation issues in = FreeBSD base seems perfectly reasonable. Expecting them to respond to = random issues in the ~24.000 ports is not. Erik= From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 15:46:35 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA07B2AE; Sun, 25 Aug 2013 15:46:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 70DB62429; Sun, 25 Aug 2013 15:46:35 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDcYR-0009YD-LY; Sun, 25 Aug 2013 19:48:39 +0400 Date: Sun, 25 Aug 2013 19:48:39 +0400 From: Slawa Olhovchenkov To: Erik Cederstrand Subject: Re: GCC withdraw Message-ID: <20130825154839.GL3796@zxy.spb.ru> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <1377440469.1111.124.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current , Ian Lepore , toolchain@FreeBSD.org, "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 15:46:35 -0000 On Sun, Aug 25, 2013 at 05:24:23PM +0200, Erik Cederstrand wrote: > Expecting FreeBSD Clang maintainers to respond to compilation issues > in FreeBSD base seems perfectly reasonable. Expecting them to > respond to random issues in the ~24.000 ports is not. OK, how FreeBSD Clang maintainers can respond to issue with firewire? I don't imagine how to do this. From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 15:57:31 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54D4D4F3; Sun, 25 Aug 2013 15:57:31 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3504D24B2; Sun, 25 Aug 2013 15:57:31 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7PFvUdn060144; Sun, 25 Aug 2013 08:57:30 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7PFvUdZ060143; Sun, 25 Aug 2013 08:57:30 -0700 (PDT) (envelope-from sgk) Date: Sun, 25 Aug 2013 08:57:30 -0700 From: Steve Kargl To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130825155730.GA59962@troutmask.apl.washington.edu> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 15:57:31 -0000 On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote: > On 25 Aug 2013, at 00:06, Steve Kargl wrote: > > > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >> > >>> And i found PR about clang and mplayer: ports/176272 > >>> This PR contains log with build error log. > >> > >> Please file clang bugs at http://llvm.org/bugs/ > >> > > > > As if this is going to help. > > > > http://llvm.org/bugs/show_bug.cgi?id=8532 > > > > 2 years, 9 month and counting. > > This bug relates to a corner case in complex floating point support, > which GCC in base doesn't get right either, GCC addressed issue in 4.5.0. I don't necessarily agree with the fix, but gcc did not ignore it. I understand why FreeBSD has not updated to a newer gcc base. > and which affects a tiny proportion of users yep, anyone using complex arithmetic. > and which comes with a hypothetical test case Of course, it is a trivial testcase. It was meant to be trivial to demonstrate the bug and aid the compiler writer in fixing it. > but no evidence that any real-world code is affected by it. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599 > If you have some real-world code that is compiled correctly > by GCC but incorrectly by clang as a result of this, then > please update the bug. Go read FreeBSD libm's code where I (and now others) had/have to jump through hoops with cpack[f|l] functions to avoid the problem. > Oh, and it's worth noting that clang, as an extension, supports > using initialiser lists to create complex values and so this > particular case is trivial to avoid if you use this feature, > which you will if you create complex numbers using the macro that > the C specification introduced specifically to avoid this case. See msun/src/math_private.h. But, the above is irrelevant. You missed my point, so to be blunt. Reporting the bug to llvm does not mean that it will be fixed. More importantly the problem with mplayer and clang should be reported/recorded in FreeBSD's bug database where others can find the issue when clang fails to build mplayer. The mplayer maintainer can either fix the problem or escaluate the issue upstream. -- Steve From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 25 17:27:10 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1C06CE6; Sun, 25 Aug 2013 17:27:09 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84C4E286E; Sun, 25 Aug 2013 17:27:09 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pb11so1534524veb.25 for ; Sun, 25 Aug 2013 10:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1mLuRBnKI+livrDmzutiZm202MdV30v4ZDJsh+YqD/E=; b=MyG89CwpW/Gm7p0S7cQcItWBjohu8Tj8YRyS5UjrBIpnweFCFLZdgh7mkkp/vqDxsa fJIQTufg43BJlUBG8L/zrzgxosjdQuLD6vBupTczBb+Qn0OGfXA1b6M2aSd+ennCxXNt 5Zj6kdmjYGXdjRNmd9kDnNJSurpxVC36Oq1gMFzIwSS1lXpA3xhRW63GdhR24KSBudJo nGKI7nmoME0ogdUFZ/Ob0pXSbd9FZCa+WfzHyKQx6HQLcarbmrufH6rhzMPUKm/4XU9u 8208G9xrPzvcouRLU3Qpha7BW1Ch1ZuaTk6A9tTWTE7dZHf7pRspYjed/uJ9B0na1wjA epuA== MIME-Version: 1.0 X-Received: by 10.58.208.130 with SMTP id me2mr10646209vec.13.1377451628565; Sun, 25 Aug 2013 10:27:08 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.220.115.206 with HTTP; Sun, 25 Aug 2013 10:27:08 -0700 (PDT) In-Reply-To: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> Date: Sun, 25 Aug 2013 19:27:08 +0200 X-Google-Sender-Auth: z6sdrhT1CyRHIfUZtEwA02tKEeM Message-ID: Subject: Re: GCC withdraw From: Ed Schouten To: David Chisnall Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , toolchain@freebsd.org, Steve Kargl , Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 17:27:10 -0000 2013/8/25 David Chisnall : > Oh, and it's worth noting that clang, as an extension, supports using ini= tialiser lists to create complex values and so this particular case is triv= ial to avoid if you use this feature, which you will if you create complex = numbers using the macro that the C specification introduced specifically to= avoid this case. Or even better, use the C11 CMPLX()/CMPLXF()/CMPLXL() macros, which are properly supported by FreeBSD -HEAD. --=20 Ed Schouten From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 26 01:03:36 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75BE0609; Mon, 26 Aug 2013 01:03:36 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6C02D6F; Mon, 26 Aug 2013 01:03:36 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (charybdis-ext.suse.de [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id DC42F3F418; Sun, 25 Aug 2013 21:03:32 -0400 (EDT) Date: Mon, 26 Aug 2013 03:03:31 +0200 (CEST) From: Gerald Pfeifer To: =?ISO-8859-15?Q?Bernhard_Fr=F6hlich?= Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-646792075-1377479013=:3920" Cc: toolchain@freebsd.org, John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 01:03:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-646792075-1377479013=:3920 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Fri, 23 Aug 2013, Bernhard Fröhlich wrote: > A possible hack could be to add a check for USE_GCC=any to behave like > a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > from ports for a lot of people on HEAD I suppose. I am planning to work on this a bit more once the two patches I submitted to portmgr this weekend (updating math/mpc, updating lang/gcc and the default ports version of GCC from 4.6 to 4.7) have made it into the tree. That said, already today when USE_GCC=any is specified and /usr/bin/gcc does not exist, USE_GCC=any basically becomes USE_GCC=yes and uses a current version of GCC, lang/gcc by default unless a different version is installed. Is this not working for you? Is there anything else that you'd like to see in Mk/bsd.gcc.mk? Gerald --0-646792075-1377479013=:3920-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 26 01:12:33 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90FFA6A8; Mon, 26 Aug 2013 01:12:33 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 64FF82DCE; Mon, 26 Aug 2013 01:12:33 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (charybdis-ext.suse.de [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id DF6BB3F419; Sun, 25 Aug 2013 21:12:31 -0400 (EDT) Date: Mon, 26 Aug 2013 03:12:30 +0200 (CEST) From: Gerald Pfeifer To: Warner Losh Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Adrian Chadd , re@freebsd.org, current@freebsd.org, John-Mark Gurney , Alfred Perlstein , toolchain@freebsd.org, "Sam Fourman Jr." X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 01:12:33 -0000 On Sat, 24 Aug 2013, Warner Losh wrote: >> "If you push gcc out to a port, and you have the 'external compiler' >> toolchain support working correctly enough to build with this, why >> don't we just push clang out to a port, and be done with it?" > This is a stupid idea. It kills the tightly integrated nature of > FreeBSD. I'd say it is far too radical a departure and opens up a > huge can of "which version of what compiler" nightmare that we've > largely dodged to date because we had one (or maybe two) compilers > in the base system. I am working towards establishing lang/gcc as _the_ version of GCC to use for ports. Today I looked at a couple of those GCC cross-compilers we have in ports, and I have to admit I am not thrilled. Each of those I saw copies a lot from (older version of my ports), each has a different maintainer, each has some additions, and there is little consistency. Are these the base of 'external compiler' toolchain support? Are there any plans to increase consistency and reduce redundancy? In an ideal world, could those become slave ports of lang/gcc? Gerald From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 26 01:21:27 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0AD4883 for ; Mon, 26 Aug 2013 01:21:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78AC62E44 for ; Mon, 26 Aug 2013 01:21:27 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id e14so4096370iej.36 for ; Sun, 25 Aug 2013 18:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zFSCZTwm61Z1Vz3wlW9j/MomllmS/YWf0kmxM5KFMnw=; b=YAjUu50KxKASn9ygCIJWYFWhOIL2v5kgD6a0JagCf4FVWPzX5uAeB3/Nd+wKiJuG2/ s31r8mBpYjgRaEfDNUBhVEqflvyfC9+3wh7ujiipWbyFOHKwzTWTmVYJqNscYQrU47ae IyJR+P4LpAGc6kLvu4uw0RvoBA/Z3ZVGKwuxNPUV7Oe/C49KpD0hxpCJd0ljyua4LjDX oAsqlcgWbzYGLbTYTP+GwcO6T0BmdjgDJahRCa+JmD+ngyqqUsxm8dTB+Z1g5olrd6dO Vq/DvGc2SmuN+DY6kCAEyEAFfMj0sOaKNxPBocWYM08EhbN/Vcf1+8DMn7rkmgFX8yBJ SNTA== X-Gm-Message-State: ALoCoQmMCT6Y2X4GTVFrXsAadtniWe+OoQ0ahSL+76DZjMSPNeq9XpBJM6oHZw4Nb+4wAe/orGwP X-Received: by 10.50.50.210 with SMTP id e18mr5107090igo.9.1377480081355; Sun, 25 Aug 2013 18:21:21 -0700 (PDT) Received: from 130.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id cl4sm15015055igc.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 18:21:20 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 25 Aug 2013 19:21:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <066F5ACF-F2EA-42FF-8D27-BFE20E20B501@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , re@freebsd.org, current@freebsd.org, John-Mark Gurney , Alfred Perlstein , toolchain@freebsd.org, "Sam Fourman Jr." X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 01:21:27 -0000 On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote: > On Sat, 24 Aug 2013, Warner Losh wrote: >>> "If you push gcc out to a port, and you have the 'external compiler'=20= >>> toolchain support working correctly enough to build with this, why=20= >>> don't we just push clang out to a port, and be done with it?" >> This is a stupid idea. It kills the tightly integrated nature of=20 >> FreeBSD. I'd say it is far too radical a departure and opens up a=20 >> huge can of "which version of what compiler" nightmare that we've=20 >> largely dodged to date because we had one (or maybe two) compilers=20 >> in the base system. >=20 > I am working towards establishing lang/gcc as _the_ version of GCC > to use for ports. >=20 > Today I looked at a couple of those GCC cross-compilers we have in=20 > ports, and I have to admit I am not thrilled. Each of those I saw > copies a lot from (older version of my ports), each has a different > maintainer, each has some additions, and there is little consistency. >=20 > Are these the base of 'external compiler' toolchain support? Are > there any plans to increase consistency and reduce redundancy? In > an ideal world, could those become slave ports of lang/gcc? In my experience, this has grown up rather hap-hazardly. Some more order = here would be good. In the past, for example, some ports had some of the = FreeBSD fixes, but not all so while I could build FreeBSD/mips gcc out = of /usr/src, I couldn't do that, even for the (then current) gcc42 port = since some of the fixes hadn't made it up stream. In an ideal world, we'd be able to build any version of gcc for any = FreeBSD platform (or have it fail up front) so we can use that as an = external toolchain. The initial work I did for external toolchains, that Brooks reworked (or = rewrote from scratch, I can't recall which he did), was with make xdev = in the tree... And that has its own set of pros and cons... All of = which are really a tangent, so I'll leave it at that. Warner From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 26 01:27:53 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4288922; Mon, 26 Aug 2013 01:27:53 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9E07C2E85; Mon, 26 Aug 2013 01:27:53 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (nat.nue.novell.com [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id 06C963F418; Sun, 25 Aug 2013 21:27:51 -0400 (EDT) Date: Mon, 26 Aug 2013 03:27:50 +0200 (CEST) From: Gerald Pfeifer To: =?ISO-8859-15?Q?Bernhard_Fr=F6hlich?= Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1041702911-1377480255=:3920" Cc: toolchain@freebsd.org, Volodymyr Kostyrko , John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 01:27:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1041702911-1377480255=:3920 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Fri, 23 Aug 2013, Bernhard Fröhlich wrote: > lang/gcc42 is on the list of ports that have USE_GCC=any. So you would > need to fix it first to be able to compile it with clang 3.3 from base. I don't think so. :-) You can install lang/gcc which builds just fine with clang, and then use lang/gcc to build lang/gcc42. In fact, if you have a system without GCC in the base, this should happen automatically when you build lang/gcc42. Does this not work? > We are not trying to build everything with lang/gcc but just the ports > that have USE_GCC=any in their Makefile. ...and those that have USE_GCC=yes in their Makefile. The difference between USE_GCC=yes and USE_GCC=any is that the later is there to support the transition period and uses /usr/bin/gcc if present. Personally, I would stop relying on /usr/bin/gcc (even if present) and use the lang/gcc port in all cases. That reduces the number of different scenarios to test, but will pull in lang/gcc in some more cases and may meet some resistance therefore. Gerald --0-1041702911-1377480255=:3920-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 26 01:41:35 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A54D8A93; Mon, 26 Aug 2013 01:41:35 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 817AD2F47; Mon, 26 Aug 2013 01:41:35 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (charybdis-ext.suse.de [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id 753373F418; Sun, 25 Aug 2013 21:41:33 -0400 (EDT) Date: Mon, 26 Aug 2013 03:41:32 +0200 (CEST) From: Gerald Pfeifer To: Volodymyr Kostyrko Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: <521751AF.6040905@gmail.com> Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: toolchain@freebsd.org, John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 01:41:35 -0000 On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: > I object. Many ports that compiles perfectly on gcc 4.2.1 can't be > compiled with lang/gcc. I checked this once and the number of ports > that require strictly gcc 4.2.1 was bigger for me then number of > ports that can't be compiled with clang but fill fine on lang/gcc. > > I'll gonna recheck whether lang/gcc42 is sufficient for them. But I > have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. Gerald From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 26 03:46:35 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E11A99C for ; Mon, 26 Aug 2013 03:46:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73B572550 for ; Mon, 26 Aug 2013 03:46:35 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb10so2907608pad.37 for ; Sun, 25 Aug 2013 20:46:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=puXfa+b8hzyct6lO3fJxsl6NTtuzp1I5OxTmgHtZFXs=; b=Z16BOYWJE4+3Tk961a85KQqOUYiFqjfvIaOzBDhK7+SwYpjDVmtXn81H+pvvKSACJJ 4FYWtPanq16tY7v2Is30+QUIHYOdGFUPckXv+2HVhDiHBt8+icWFO9+MPJPop8+xw2ew U7cZ3x8mk8GL7gN5ieGinC7DL4IIM+fb2hTE0nlCpDq9n5r5tKEg5YwrXc5iwcU5emR/ w0TZ+tI0cpN2/WfIlTT55iScGPcL1sctGpskc84LFFsfT+jI9OZUb9ZumvOUWM6gKb3V rnQbcjgyf+fj3mNpMDT+0kD6GGF4reNBl+j2JGLPTyQr1pQNiSllr8sov7HLeumSRYlL tPLA== X-Gm-Message-State: ALoCoQlPbHmevlBHfpVoZBxKJVmk1xJhgr5zU0AwoLWoQUS/MEdVeqbrAlbKVKK6/cwLlwvvRRe4 X-Received: by 10.66.161.229 with SMTP id xv5mr12392650pab.87.1377488343870; Sun, 25 Aug 2013 20:39:03 -0700 (PDT) Received: from [10.0.0.122] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qp10sm16967023pab.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 20:39:02 -0700 (PDT) References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Date: Sun, 25 Aug 2013 21:38:55 -0600 To: Gerald Pfeifer Cc: "toolchain@freebsd.org" , Volodymyr Kostyrko , John-Mark Gurney , "current@freebsd.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 03:46:35 -0000 Can all such ports be identified with a ports build run in a special chroot w= ithout FreeBSD's FCC installed? Sent from my iPad On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer wrote: > On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: >> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be=20 >> compiled with lang/gcc. I checked this once and the number of ports=20 >> that require strictly gcc 4.2.1 was bigger for me then number of=20 >> ports that can't be compiled with clang but fill fine on lang/gcc. >>=20 >> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I=20 >> have that bad feeling... >=20 > If there are ports that use USE_GCC=3Dany and do not build with > lang/gcc, these should have USE_GCC=3D4.2 -- without a '+'! -- > not USE_GCC=3Dany. >=20 > It'll be great if you can fix any such port. >=20 > Gerald > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.or= g" From owner-freebsd-toolchain@FreeBSD.ORG Tue Aug 27 14:47:48 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BE7BAE0; Tue, 27 Aug 2013 14:47:48 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4ECD02CB8; Tue, 27 Aug 2013 14:47:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MS7009002AA5B00@smtpauth3.wiscmail.wisc.edu>; Tue, 27 Aug 2013 09:47:41 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.22.10622, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (172-12-164-50.lightspeed.wlfrct.sbcglobal.net [172.12.164.50]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MS700FXT2E6MX40@smtpauth3.wiscmail.wisc.edu>; Tue, 27 Aug 2013 09:46:57 -0500 (CDT) Message-id: <521CBBDE.6030503@freebsd.org> Date: Tue, 27 Aug 2013 07:46:54 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 To: Gerald Pfeifer Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> In-reply-to: X-Enigmail-Version: 1.5.1 Cc: toolchain@freebsd.org, Volodymyr Kostyrko , John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 14:47:48 -0000 On 08/25/13 18:41, Gerald Pfeifer wrote: > On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: >> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be >> compiled with lang/gcc. I checked this once and the number of ports >> that require strictly gcc 4.2.1 was bigger for me then number of >> ports that can't be compiled with clang but fill fine on lang/gcc. >> >> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I >> have that bad feeling... > If there are ports that use USE_GCC=any and do not build with > lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- > not USE_GCC=any. > > It'll be great if you can fix any such port. It would be particularly nice if we had a port with FreeBSD's many patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on powerpc64, for example, while our in-tree GCC does. -Nathan From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 14:58:25 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A05048C6; Thu, 29 Aug 2013 14:58:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 748F82DBF; Thu, 29 Aug 2013 14:58:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 65DD0B9C1; Thu, 29 Aug 2013 10:58:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: GCC withdraw Date: Thu, 29 Aug 2013 10:57:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130822200902.GG94127@funkthat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291057.43027.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 10:58:24 -0400 (EDT) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 14:58:25 -0000 On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: > On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote: > > > So I vote, let's not give ourselves the burden of "lugging" dead weight in > > base > > for another 5 years. (in 2017 do we still want to be worrying about gcc in > > base?) > > Perhaps more to the point, in 2017 do we want to be responsible for > maintaining a fork of a 2007 release of gcc and libstdc++? This is a red herring and I'd wish you'd stop bringing it up constantly. GCC has not needed constant care and feeding in the 7.x/8.x/9.x branches and it won't need it in 10.x either. I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. -- John Baldwin From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 16:03:03 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F24D7170 for ; Thu, 29 Aug 2013 16:03:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B89772421 for ; Thu, 29 Aug 2013 16:03:03 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id v19so674533obq.25 for ; Thu, 29 Aug 2013 09:02:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9z81+8ESM1A0yIrLB6HtD0tcWXlCC0WMjaAf8JBlLMI=; b=JSvTR6DaBOfOyVohxrAekZiJlg1BE79aHdVc2/20vAyQ/2b1amakW9d6F9NRLcuO5U O/f4KvaI4mYKMxyr9Ci4Tkcm9O7Xaz055A2Jm4kbpJKWEQd3Kpm8G7uxLnbk7QERosVh Mikryv+wdlKj0UUu+uElbZw91qdKsa2jCBvVOZk53die5J+8N84AUqg5/860xqO2wadE CzUw+BrbcViwxatJnnTPosbLaq0yHcru4+bubqwDzZHt0bB/rnBMU8ENf5Ks1Yq0xj6g wdIfp2G70ETbNU5M0rRifVb3TGIQ7HLk0L7jqeca0A/O+30kyq2Z+LGMt5z6xlsyJrWN ZV5Q== X-Gm-Message-State: ALoCoQkghR3hJ/bU5Brw9NJ5WwtiuBNjRZjXAniJB4nhEC/OItxeVFDi/qV1d18ctaVlZUHTEnob X-Received: by 10.60.38.164 with SMTP id h4mr3075747oek.22.1377792177616; Thu, 29 Aug 2013 09:02:57 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id r3sm33102972oep.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 09:02:56 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <521CBBDE.6030503@freebsd.org> Date: Thu, 29 Aug 2013 10:02:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> <521CBBDE.6030503@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1085) Cc: current@freebsd.org, Volodymyr Kostyrko , toolchain@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 16:03:04 -0000 On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote: > On 08/25/13 18:41, Gerald Pfeifer wrote: >> On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: >>> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be=20= >>> compiled with lang/gcc. I checked this once and the number of ports=20= >>> that require strictly gcc 4.2.1 was bigger for me then number of=20 >>> ports that can't be compiled with clang but fill fine on lang/gcc. >>>=20 >>> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I=20= >>> have that bad feeling... >> If there are ports that use USE_GCC=3Dany and do not build with >> lang/gcc, these should have USE_GCC=3D4.2 -- without a '+'! -- >> not USE_GCC=3Dany. >>=20 >> It'll be great if you can fix any such port. >=20 > It would be particularly nice if we had a port with FreeBSD's many > patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on > powerpc64, for example, while our in-tree GCC does. I think it would be more than "nice" to have. I'd argue that these = issues need to be addressed before we can claim to have a full = external-supported toolchain story that's integrated and well tested and = covers the needs of all our users. Warner From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 16:06:34 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6DF2523D for ; Thu, 29 Aug 2013 16:06:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34BDB245B for ; Thu, 29 Aug 2013 16:06:34 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id o20so840040oag.19 for ; Thu, 29 Aug 2013 09:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/UhBaMQzsCkEvg6hrbtdN7tsQsTKlvYHTJTlzZ5a2Bk=; b=jX8AHgRrvB6Rc4R2/MsJdUSPxYYseVVWW14UDT3QMsSd8N2AQwGGU7cFidlOUuoQsE 4IGD/qqEI2trvhehO3CYPXzvi8U57HfBU+PTDGn/MMEHLfDqw4LquGsMytIT7+YCojsM vLfx6dwzv9gvmBcst4JEzqNEwDXUQGmn1eCCEm83kiYU17/afxyD5hv3MgMayOLFjcCJ HrOx0CGbFh24kpTqRTqqhoYf7CPhnzcjvgrcct8ZlQcegzt9mcd4UwRhUFdoJHqsV3vX rdf2bVsob+5exz2R8n9hmT4WzmHu8IeqhNLC6A6v36U2Yr5sfhmD9kbLh6t4/ebq+jWr 5a1A== X-Gm-Message-State: ALoCoQmpbFLtGniKaDRSRwrbyp7DCzfv799YOzg77GscTVOqOl4sVXUF0MWE0C2+o60TMQeQCmA9 X-Received: by 10.60.70.134 with SMTP id m6mr3060094oeu.14.1377792022904; Thu, 29 Aug 2013 09:00:22 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id tz10sm32053985obc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 09:00:22 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201308291057.43027.jhb@freebsd.org> Date: Thu, 29 Aug 2013 10:00:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , toolchain@freebsd.org, freebsd-current@freebsd.org, "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 16:06:34 -0000 On Aug 29, 2013, at 8:57 AM, John Baldwin wrote: > On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: >> On 24 Aug 2013, at 11:30, "Sam Fourman Jr." = wrote: >>=20 >>> So I vote, let's not give ourselves the burden of "lugging" dead = weight in >>> base >>> for another 5 years. (in 2017 do we still want to be worrying about = gcc in >>> base?) >>=20 >> Perhaps more to the point, in 2017 do we want to be responsible for >> maintaining a fork of a 2007 release of gcc and libstdc++? >=20 > This is a red herring and I'd wish you'd stop bringing it up = constantly. > GCC has not needed constant care and feeding in the 7.x/8.x/9.x = branches > and it won't need it in 10.x either. I have not seen any convincing > argument as to why leaving GCC in the base for 10.x impedes anything. > Because clang isn't sufficient for so many non-x86 platforms we can't > really start using clang-specific features yet anyway. Agreed. Gcc is still an absolute requirement on all non-x86 platforms = (including arm) due to the issues with clang. Some of these issues are = bugs in specific things (arm) that keep coming up (and keep getting = fixed), while others are more severe (sparc64 has no clang support, and = no way to generate a self-hosting system in the absence of a bootstrap = gcc in the base, even with the external toolchain support). gcc will absolutely be in the base for 10. That's the long-standing = agreement that we've had, and breaking it now at the 11th hour is going = to totally screw up !x86 platforms and really piss off a lot of = developers for no good reason. The time is long since past to change = this plan. This is the plan of record, and we need to stick to it: 10: clang default, where possible, gcc in base otherwise 11: clang default, full external toolchain support, including = self-hosting So the time for voting and carping has long since past. Warner= From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 16:57:22 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B12629D5 for ; Thu, 29 Aug 2013 16:57:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 746A027FC for ; Thu, 29 Aug 2013 16:57:22 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id o17so922948oag.7 for ; Thu, 29 Aug 2013 09:57:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ud05ZE5HwalOMowLinY+f8RHwPh/eJtN+7YBkb2y0YA=; b=lqTHtjLp3nUe71glGr+yolui7Mjc9vaNJJOuLIV2f8cj/caVJf0uUadGO7oXEYpsKf PkMXuhacEhZty8p7VPHjNgTdk6Xjswkj+TXvTxBm+R5vCTEp8KrvTjo7N0bYbf8snfRH GEup15IST6sxbh+wZ5Eq/De25XFvx2d9PBWvfvg46Ogjp+4P3+qiXYS1wn2DgWRQLrPy 1eVFMvGhyHZZd7qCwVz5ghSYPS5OQrLtHe7uxHgKZOAFEMC2KLjQN2dVd9SANl5VgPME ZjxUs132FRkwNu+DWfC6AM+u+IqpdOIYfdJcI2INbyDr7GUDxR+tQbEMSRXfHkEpFKDN 2rwA== X-Gm-Message-State: ALoCoQn7ei3Z4H4I2jDCL08lCIZbp0ZLXcLWaXF/74QkKGWdU/fW7bW4KMXpvq/yPmIakthACHNP X-Received: by 10.60.115.226 with SMTP id jr2mr626422oeb.95.1377795441506; Thu, 29 Aug 2013 09:57:21 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id hl3sm32302657obb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 09:57:20 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1377440469.1111.124.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 10:57:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9B13FF68-35F4-4A7C-8AD3-F72BA28718E8@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <1377440469.1111.124.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , toolchain@FreeBSD.org, Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 16:57:22 -0000 On Aug 25, 2013, at 8:21 AM, Ian Lepore wrote: > On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: >>=20 >>> And i found PR about clang and mplayer: ports/176272 >>> This PR contains log with build error log. >>=20 >> Please file clang bugs at http://llvm.org/bugs/ >>=20 >> David > And THIS is a major reason why FreeBSD needs a compiler in base = instead > of all tools being ports. The last thing we need is to start = responding > to every problem with "this is not my problem, go file a report > upstream." If we're already doing it for the compiler that's supposed > to be the new supported tool, how much worse will peoples' experience = be > when we assert no ownership or responsibility for a toolchain at all? Especially when the external toolchain support is far from well = integrated, is lacking key features and needs much documentation on what = is there. One of the huge draws to FreeBSD is that you don't have to play = whack-a-mole with gcc/binutils/libc/etc. I'd sure hate to lose that. Warner From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 17:02:16 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84270DD3; Thu, 29 Aug 2013 17:02:16 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D567285F; Thu, 29 Aug 2013 17:02:15 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7TH2CeY002055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Aug 2013 17:02:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308291057.43027.jhb@freebsd.org> Date: Thu, 29 Aug 2013 18:02:06 +0100 Message-Id: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 17:02:16 -0000 --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Aug 2013, at 15:57, John Baldwin wrote: > I have not seen any convincing > argument as to why leaving GCC in the base for 10.x impedes anything. > Because clang isn't sufficient for so many non-x86 platforms we can't > really start using clang-specific features yet anyway. Apparently I haven't been good at communicating, so I'll try to here. I = apologise for ignoring this thread for the last week: I've been rather = busy organising the DevSummit. The notes for the sessions will be = posted to various mailing lists soon (and summarised for a special = status report), but since the ports and toolchain build sessions are = already largely up you can check these on the wiki. You'll notice that = in both sessions the topic of removing gcc / libstdc++ was raised and = there was no objection (not sure if it's in the notes, but there was a = lot of support during the ports session from people who didn't want the = pain of maintaining compatibility with gcc-in-base, and especially with = g++/libstdc++ in base). =20 This is not a new plan, it is the plan that has been on the wiki and = discussed at at least two DevSummits that I have attended before this = week and probably others that I missed, as well as on various mailing = lists and in IRC. =20 To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports = C++03. It doesn't support C++11 at all and never will, nor does it = support C++14. An increasing number of ports are depending on C++11, = because it provides much cleaner syntax than C++98 and so these are = being forced to depend on gcc46 or gcc47 to build. Unfortunately, = libstdc++ in ports is not ABI compatible with the libstdc++ that we = ship, which causes library ABI versions. This problem will only get = worse over the coming years. An increasing number of these ports do = build with libc++ (since it's the only option on OS X / iOS - most do = already and most of the fixes needed are just adding some inclusions = since libc++ doesn't leak C headers as much as libstdc++), so defaulting = to libc++ will reduce these problems over time. =20 Maintaining our libstdc++ is not a zero-effort operation. We have to = modify it whenever libc gains new features (e.g. POSIX2008 locales, new = libm functions) and this requires developer time tracking down the new = bugs (because the static configuration files no longer match the = included headers) and fixing them. Maintaining out gcc is also not a zero-effort operation. Even though it = is not the default compiler for amd64 or i386, we still have to add = support for new instructions to them, even if we only want to use them = in machine-dependent code on these architecture. =20 Our g++ in base can only work with libstdc++, not libc++. This means = that shipping gcc in 10.0 in base means that we'd be shipping two C++ = compilers, which preferred different standard libraries, with = incompatible ABIs. This is setting us up for a world of pain. When we enable LLDB during the 10.x timeframe (emaste has been working = hard, but it's probably not quite ready for 10.0), it will have to link = against both LLVM libraries and libc++ (as it uses C++11 and doesn't = work with our libc++). This is a minor issue, as the only requirement = here is that we switch to linking LLVM against libc++ instead of = libstdc++, but it is an example of one more piece of code that won't = build with our gcc that is in the base system (not yet enabled by = default). Clang 3.4 will not build with our gcc either (which will = cause some bootstrapping problems that we'll have to address for people = going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as = long as we tweak the build system to use clang and not cc for the = bootstrap build). Lots of configure scripts will use gcc in preference to cc (or g++ in = preference to c++) if they find them in the same place. Many of these = no longer work with our old gcc, but do work with clang, adding more = effort to ports. According to the test runs that bapt did at the = DevSummit this week, we have more ports failing on 10 with gcc than on = 10 with gcc removed. Our gcc does not support the ARM EABI hard float variant. I misspoke = earlier when I thought it didn't support EABI at all, but it turns out = that it's only the case for hard-float. This is the ABI that we want to = be using on pretty much all ARMv6 and newer systems, because a lot of = ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has = paid for FreeBSD to be ported on to use as a demo ARM device) require a = complete pipeline flush when moving between integer and floating point = registers and the soft-float variant of the ABI puts all arguments in = integer registers. This means that a simple function that takes a = rectangle (4 floating point values) as an argument will require 8 = pipeline flushes to call, which various Linux distributions have found = is crippling for graphical applications. =20 We want to start shipping binary packages for ARMv6. At the moment, = i386, amd64, and ARMv6 are the only architectures where you can get = cheap, off-the-shelf, hardware that looks enough like a normal computer = that you'd expect to be able to use a stock install, and so they are the = only platforms where the default build configuration makes a difference. = For all of these preferences, clang is the default and there is no = reason to prefer our gcc: if you actually want to use gcc (e.g. if you = care about the C99 floating point craziness, or you have OpenMP code to = build) then one of the gcc versions in ports will give you much better = code (and better error reporting). =20 Unlike clang, gcc is not intrinsically a cross compiler. This means = that if you are targeting a non-x86, non-ARM architecture then you are = already building a cross-gcc to use as part of your bootstrap process = and so not having the x86-only gcc on your host system does not cost you = anything. As someone who spends day-job time working on FreeBSD/MIPS, = I've never found the need to use the installed base-gcc (my life would = be much happier if we had some nice infrastructure for building packages = of the MIPS toolchain, headers, and shared libraries, but that's an = unrelated issue). =20 The tinderboxes will prevent any gcc-incompatible code from appearing in = the MI bits of the kernel. Optional parts of the userland can slowly = migrate to supporting newer language features. =20 Last but not quite least, people keep complaining about ever-increasing = build times and the size of the base system. Building a gcc and = libstdc++ by default every time, that we're telling people not to use, = won't help with that... I have not heard any compelling arguments for keeping gcc and libstdc++ = as part of the default install on x86, and I have listed a number of = reasons why doing so creates extra work for people who maintain the = toolchain and who work on ports. I intend to commit the change to = remove both from the default build and make libc++ the default STL for = clang++ as soon as I get an okay from bapt. =20 David --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSH36PAAoJEKx65DEEsqIdb7YQAJoGYPQdMLAPwhHHrLa3Rvl5 efXPgzzMs5vgVjLi3xd3PFy7jDJVeG9SoGOc+BhnC5mWM12aa6vtP21krogCHlkt O59ApLiPE0orcLcNQYgdqxGZmoKCGRHYrGtCd6Ztvp3pKfcgwmXPJ47VPRjntIDN TvFNNEO2GnKiHUpOZZVw5g6kYcQT6lz9gigjNzW2k/662T0quoiJSGwNW6wsf9Is NQDSxGh4SVPGrtAvShY6FW31a0iWyAn42q7TmIA9tgjQIiLVFn3MG4ijWDp2YDXV dIJe6SaC+YmRy5Y2ajf9lraKRB3eZaquUhT2VzWvTx3hbDh5ng+Wat81UuEC04KI 1srCjkkHRgV+U7PPD+sjz9FUxXdpaevpcn35WepOsKqF2M/j31tg1qeB+oIaovPM SDEgaR50QR9o/LKKFaqSJMnyyzIRdFRK8SiWz8BPFrrWPW79MS5jtH12Nd6nSAcq kIiyqYSMm0ZuuAiPSsVUEY1q0Dd3snajlT5dWrCl7bdSawV26uk/15lGDRiYo9I0 xsZ0oVQn4itkCQ9DS25OwdAR5w5gRy/tmnmIOm1C8YEUBfb+4BHq1YZlmLfAlkBz lvChjb41fnHKcjgJ3nGzk4+BoHelEc46Ggnc9uqMEF2muboeFPazm2gBbc/sAODm bFuhOfRbt4PHMXMNKv+r =zkC2 -----END PGP SIGNATURE----- --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 17:22:03 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7750AFB for ; Thu, 29 Aug 2013 17:22:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C10B29DD for ; Thu, 29 Aug 2013 17:22:03 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so780803obc.20 for ; Thu, 29 Aug 2013 10:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T1iQD6QrxM9x42tWOEQg+Q8k8Bb52BHKR7Ia+HQYb9I=; b=UpzJ6aOcstlRndTnnJ2Oc0HTMgjer84ULgPQn/OX3DScms1EGCRSsOUrlOANS4jdXn jzfmlF0KrTTmlvu8XK651JZWcWx5ZHwp/dAwPcSLMzuQSYuF1pDps5LlI7rOcZl2HU/R EOYKORY6gIjQ2P7WR4/CQEPuXhhM87Z11JzJJqxedcjBrJncfhmPXBAvXQo4Wv8VoFb7 BAHnQ9ri1u7vzSQmQMKUZNQ+6SAroQA5cwjrjKL6q3f4ZSr9hlxmFMtn2B1uvTHYbARK w5T46OrPwVnTCvvg7U8psZRhFFHs8LlCiH3A+JhYsyoZMk4CDOp5he5RW2GQaYXWV4zv SE0Q== X-Gm-Message-State: ALoCoQnHpOuuuZk3kdXKx38SUPgdVptAvt/4jyl9Qi7+ZE63kXhYvf07OwKbC/OV37h8XcwxeXTQ X-Received: by 10.60.51.7 with SMTP id g7mr3468744oeo.6.1377796922709; Thu, 29 Aug 2013 10:22:02 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id z5sm32455135obg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 10:22:01 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> Date: Thu, 29 Aug 2013 11:21:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0678F678-A140-4A69-AF46-EA1C036DAA1A@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , John Baldwin , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 17:22:04 -0000 On Aug 29, 2013, at 11:02 AM, David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin wrote: >=20 >> I have not seen any convincing >> argument as to why leaving GCC in the base for 10.x impedes anything. >> Because clang isn't sufficient for so many non-x86 platforms we can't >> really start using clang-specific features yet anyway. >=20 > Apparently I haven't been good at communicating, so I'll try to here. = I apologise for ignoring this thread for the last week: I've been rather = busy organising the DevSummit. The notes for the sessions will be = posted to various mailing lists soon (and summarised for a special = status report), but since the ports and toolchain build sessions are = already largely up you can check these on the wiki. You'll notice that = in both sessions the topic of removing gcc / libstdc++ was raised and = there was no objection (not sure if it's in the notes, but there was a = lot of support during the ports session from people who didn't want the = pain of maintaining compatibility with gcc-in-base, and especially with = g++/libstdc++ in base). =20 >=20 > This is not a new plan, it is the plan that has been on the wiki and = discussed at at least two DevSummits that I have attended before this = week and probably others that I missed, as well as on various mailing = lists and in IRC. =20 >=20 > To summarise the current issues: >=20 > Our libstdc++ is ancient. It supports C++98 well, it kind-of supports = C++03. It doesn't support C++11 at all and never will, nor does it = support C++14. An increasing number of ports are depending on C++11, = because it provides much cleaner syntax than C++98 and so these are = being forced to depend on gcc46 or gcc47 to build. Unfortunately, = libstdc++ in ports is not ABI compatible with the libstdc++ that we = ship, which causes library ABI versions. This problem will only get = worse over the coming years. An increasing number of these ports do = build with libc++ (since it's the only option on OS X / iOS - most do = already and most of the fixes needed are just adding some inclusions = since libc++ doesn't leak C headers as much as libstdc++), so defaulting = to libc++ will reduce these problems over time. =20 True, but this doesn't cause any problems for gcc, just g++. > Maintaining our libstdc++ is not a zero-effort operation. We have to = modify it whenever libc gains new features (e.g. POSIX2008 locales, new = libm functions) and this requires developer time tracking down the new = bugs (because the static configuration files no longer match the = included headers) and fixing them. Fair enough, but the number of these has been, to date, quite small. > Maintaining out gcc is also not a zero-effort operation. Even though = it is not the default compiler for amd64 or i386, we still have to add = support for new instructions to them, even if we only want to use them = in machine-dependent code on these architecture. =20 It actually is close to zero effort. The effort level is quite small, as = evidence by the small number of commits to gcc over time. Not zero, but = not as huge a deal as you make it out to be. However, we still need to make the efforts so long as it is part of the = base. > Our g++ in base can only work with libstdc++, not libc++. This means = that shipping gcc in 10.0 in base means that we'd be shipping two C++ = compilers, which preferred different standard libraries, with = incompatible ABIs. This is setting us up for a world of pain. This is a legitimate issue, for g++, not for gcc. But on !x86 targets = we'll need to continue to do this. > When we enable LLDB during the 10.x timeframe (emaste has been working = hard, but it's probably not quite ready for 10.0), it will have to link = against both LLVM libraries and libc++ (as it uses C++11 and doesn't = work with our libc++). This is a minor issue, as the only requirement = here is that we switch to linking LLVM against libc++ instead of = libstdc++, but it is an example of one more piece of code that won't = build with our gcc that is in the base system (not yet enabled by = default). Clang 3.4 will not build with our gcc either (which will = cause some bootstrapping problems that we'll have to address for people = going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as = long as we tweak the build system to use clang and not cc for the = bootstrap build). Seems more like an issue for 11 not 10. Also, we need to be able to bootstrap the base tools with gcc, since = that's been the fallback bootstrap method for some time for people = upgrading from really old systems: build the system with clang disabled = the first time, and then use that to bootstrap clang since the gcc there = can build it. I'd hate to loose this fallback plan, but do recognize at = some point we must. > Lots of configure scripts will use gcc in preference to cc (or g++ in = preference to c++) if they find them in the same place. Many of these = no longer work with our old gcc, but do work with clang, adding more = effort to ports. According to the test runs that bapt did at the = DevSummit this week, we have more ports failing on 10 with gcc than on = 10 with gcc removed. Won't this still be an issue for !x86? > Our gcc does not support the ARM EABI hard float variant. I misspoke = earlier when I thought it didn't support EABI at all, but it turns out = that it's only the case for hard-float. This is the ABI that we want to = be using on pretty much all ARMv6 and newer systems, because a lot of = ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has = paid for FreeBSD to be ported on to use as a demo ARM device) require a = complete pipeline flush when moving between integer and floating point = registers and the soft-float variant of the ABI puts all arguments in = integer registers. This means that a simple function that takes a = rectangle (4 floating point values) as an argument will require 8 = pipeline flushes to call, which various Linux distributions have found = is crippling for graphical applications. =20 True, but we're using it now for EABI w/o issue except for doing soft = floats. Yes, this is a problem, but we don't have all the infrastructure = in place to do hard floating point yet. So absent the required = infrastructure to do hard float, this point shouldn't have much weight. = What we do on ARM has no bearing on x86 anyway. So this is more of an interesting side note for future effort that has = no bearing at all on the issue at hand. > We want to start shipping binary packages for ARMv6. At the moment, = i386, amd64, and ARMv6 are the only architectures where you can get = cheap, off-the-shelf, hardware that looks enough like a normal computer = that you'd expect to be able to use a stock install, and so they are the = only platforms where the default build configuration makes a difference. = For all of these preferences, clang is the default and there is no = reason to prefer our gcc: if you actually want to use gcc (e.g. if you = care about the C99 floating point craziness, or you have OpenMP code to = build) then one of the gcc versions in ports will give you much better = code (and better error reporting). =20 clang generates good code on the ARM, but we still keep hitting issues = on the arm with it that go away when gcc is used. This argument, though = is not an argument for why gcc shouldn't be built, but rather why clang = should be default. Again, not relevant to the issues at hand. We've had = enough problems on arm that we must continue to have gcc easily and = readily available. > Unlike clang, gcc is not intrinsically a cross compiler. This means = that if you are targeting a non-x86, non-ARM architecture then you are = already building a cross-gcc to use as part of your bootstrap process = and so not having the x86-only gcc on your host system does not cost you = anything. As someone who spends day-job time working on FreeBSD/MIPS, = I've never found the need to use the installed base-gcc (my life would = be much happier if we had some nice infrastructure for building packages = of the MIPS toolchain, headers, and shared libraries, but that's an = unrelated issue). =20 This is total bollox. gcc is intrinsically a cross compiler and has been = since 2.0. Our use of it is so limited that you might think that gcc = isn't intrinsically a cross compiler. Also, I often install the base gcc compiler using the 'xdev' targets. = This allows me to hack together primitive port cross building support = because it installs all the right links for gnu configure based scripts = to generally work things out. Again, this is more of a use = (freebsd-arm-gcc vs gcc -Bfreebsd-arm) due to how we build gcc. We = could, in theory, build all the back ends into our gcc, but we chose a = long time ago not to do that. But this also is not a relevant point to your argument. It is a cool = feature that we build clang to include all the other targets, but not = relevant to whether to keep gcc in or out of the base system on x86. > The tinderboxes will prevent any gcc-incompatible code from appearing = in the MI bits of the kernel. Optional parts of the userland can slowly = migrate to supporting newer language features. =20 At the expense of the tree being broken more often, but this will be = true whether or not gcc is enabled by default. > Last but not quite least, people keep complaining about = ever-increasing build times and the size of the base system. Building a = gcc and libstdc++ by default every time, that we're telling people not = to use, won't help with that... Also an orthogonal issue. > I have not heard any compelling arguments for keeping gcc and = libstdc++ as part of the default install on x86, and I have listed a = number of reasons why doing so creates extra work for people who = maintain the toolchain and who work on ports. I intend to commit the = change to remove both from the default build and make libc++ the default = STL for clang++ as soon as I get an okay from bapt. =20 If you are going to do this, then doing it before 10 is best. The stdc++ = issue is a compelling one. The base gcc (not g++) is much less so. Warner= From owner-freebsd-toolchain@FreeBSD.ORG Thu Aug 29 17:46:23 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2A5528D; Thu, 29 Aug 2013 17:46:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EE4E2BE3; Thu, 29 Aug 2013 17:46:23 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56E5AB989; Thu, 29 Aug 2013 13:46:22 -0400 (EDT) From: John Baldwin To: David Chisnall Subject: Re: GCC withdraw Date: Thu, 29 Aug 2013 13:44:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201308291344.25562.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 13:46:22 -0400 (EDT) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 17:46:23 -0000 On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin wrote: > To summarise the current issues: > > Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. How does removing GCC from base change this? I already deal with having 3 different GCC versions at work by building them from ports and building things with the right rpath, etc. so I am familiar with this, and having GCC in the base doesn't make that problem any worse. In fact, I'd argue that this is an argument for not shipping an STL in the base system at all (though I'd be loathe to do that) if it is an argument for disabling GCC. > Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Strictly speaking you do not have to modify it in all cases. The recent change to make it work with log10 does not appear to have been a requirement to fix anything (at least judging from the log message). There does seem to have been about 10 changes to libstdc++ in the past year, though a few were 2-3 line changes in config.h which isn't but so earth-shattering. Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. > Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine- dependent code on these architecture. The new instructions (and I've added some) go into binutils, not gcc per se. Even the ARM ABI changes only touched Makefiles and one config header in contrib/gcc, not actual code changes. The code changes in contrib/gcc to add more AMD instrinics were done because someone felt like doing it, not because it was a requirement or blocking issue for someone. > When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Eh, it sounds like if you have to force them to use clang for 9.x bootstrapping that also solves your problem in 10, so it's the same amount of work either way. > Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system. Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC to build. :) > I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports. I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt. I posit that it only saves you work if you short-change non-x86 platforms, and that this will be harder to detect without gcc built on x86. I do think there is a decent chance that non-clang platforms will be more aggressively abandoned as a result of this change. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. -- John Baldwin From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 07:18:45 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D7CE22E; Fri, 30 Aug 2013 07:18:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C51D02C14; Fri, 30 Aug 2013 07:18:44 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7U7IaHg031377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 00:18:39 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52204746.2070900@freebsd.org> Date: Fri, 30 Aug 2013 15:18:30 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , John Baldwin , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:18:45 -0000 On 8/30/13 1:02 AM, David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin wrote: > >> I have not seen any convincing >> argument as to why leaving GCC in the base for 10.x impedes anything. >> Because clang isn't sufficient for so many non-x86 platforms we can't >> really start using clang-specific features yet anyway. > Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). > > This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. > > To summarise the current issues: > > Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. > > Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. > > Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. > > Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. > > When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). > > Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports. According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed. > > Our gcc does not support the ARM EABI hard float variant. I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float. This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers. This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications. > > We want to start shipping binary packages for ARMv6. At the moment, i386, amd64, and ARMv6 are the only architectures where you can get cheap, off-the-shelf, hardware that looks enough like a normal computer that you'd expect to be able to use a stock install, and so they are the only platforms where the default build configuration makes a difference. For all of these preferences, clang is the default and there is no reason to prefer our gcc: if you actually want to use gcc (e.g. if you care about the C99 floating point craziness, or you have OpenMP code to build) then one of the gcc versions in ports will give you much better code (and better error reporting). > > Unlike clang, gcc is not intrinsically a cross compiler. This means that if you are targeting a non-x86, non-ARM architecture then you are already building a cross-gcc to use as part of your bootstrap process and so not having the x86-only gcc on your host system does not cost you anything. As someone who spends day-job time working on FreeBSD/MIPS, I've never found the need to use the installed base-gcc (my life would be much happier if we had some nice infrastructure for building packages of the MIPS toolchain, headers, and shared libraries, but that's an unrelated issue). > > The tinderboxes will prevent any gcc-incompatible code from appearing in the MI bits of the kernel. Optional parts of the userland can slowly migrate to supporting newer language features. > > Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system. Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that... > > I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports. I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt. > > David David, we all appreciate the work you are doing here but you are just not listening.. Many of the older and more experienced voices in the project are telling you "let it sit quietly as a non default lifeboat in 10.x and remove it in 11" This comes not from our dislike of clang but from our experience in the past. Clang is new. clang WILL HAVE BUGS. Having the old compiler in the tree will save people's hides and will also allow then to say "I compiled it with gcc and it worked as expected" without having to go to ports and follow some set of instructions. As far as I'm concerned we can even slate it for "possible removal in 10.2-- if clang has proven up to the task" as long as it's widely announced in 10.*0* and people know that it's coming.. We guarantee default behaviour won't change but we don't necessarily guarantee that NOTHING will change in a branch lifetime. Julian From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 07:33:32 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 594C7582; Fri, 30 Aug 2013 07:33:32 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 170CC2D0F; Fri, 30 Aug 2013 07:33:31 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7U7XPBX007290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 07:33:26 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308291344.25562.jhb@freebsd.org> Date: Fri, 30 Aug 2013 08:33:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:33:32 -0000 On 29 Aug 2013, at 18:44, John Baldwin wrote: > How does removing GCC from base change this? I already deal with = having > 3 different GCC versions at work by building them from ports and = building > things with the right rpath, etc. so I am familiar with this, and = having > GCC in the base doesn't make that problem any worse. In fact, I'd = argue > that this is an argument for not shipping an STL in the base system at = all > (though I'd be loathe to do that) if it is an argument for disabling = GCC. It means that you don't need to patch configure scripts to tell them to = ignore gcc even if they find it. Please talk to port maintainers about = the amount of effort that they're being forced to put into this. = They'll still have to keep doing this until 9.x is EOL'd, but it would = be nice if they could then stop, rather than having to wait for 10.x to = also be EOL'd. >> Maintaining our libstdc++ is not a zero-effort operation. We have to = modify=20 > it whenever libc gains new features (e.g. POSIX2008 locales, new libm=20= > functions) and this requires developer time tracking down the new bugs=20= > (because the static configuration files no longer match the included = headers)=20 > and fixing them. >=20 > Strictly speaking you do not have to modify it in all cases. The = recent=20 > change to make it work with log10 does not appear to have been a = requirement=20 > to fix anything (at least judging from the log message). There does = seem to=20 > have been about 10 changes to libstdc++ in the past year, though a few = were=20 > 2-3 line changes in config.h which isn't but so earth-shattering. And each libc change that exposes anything that is used by libstdc++ = goes through the same cycle: - Commit - Wait for bug reports - Spend a few hours trying to work out why C++ programs are failing to = run or compile in odd ways - Commit a libstdc++ fix And, once again, the people who are advocating for gcc to remain in the = default install are not the ones doing this work. > Also, unless you plan on desupporting all non-x86 platforms, you = _still_ > have to do all this work while those platforms require GCC anyway. = Just > turning off GCC on x86 doesn't change this problem one iota. And that = point > is actually relevant to many of the other concerns you raised. It's = not at > all clear what disabling GCC on x86 will buy you unless you are = intending on > short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are = best effort. We don't need to be quite as careful to ensure that they = build with the base system compiler on tier-2 architectures. We don't = make as strong guarantees about compatibility on tier-2 architectures, = so removing gcc from their build at some point over the next five years = is fine, but this is not the case for tier 1 architectures, where we can = be reasonably expected to support anything that is in the base system = for the next five years. =20 If we remove it from the default install now, users don't expect it to = keep working for the lifetime of the 10.x branch. If we leave it in, = then they do. If tier-2 architectures are still using it for 10.0, = that's fine, because users of tier-2 architectures don't expect = everything to remain stable over the span of a release. =20 ARM is technically Tier-2, but for the purpose of this I'm including = modern ARM platforms (i.e. things like the Efika and Raspberry Pi, where = we hope to get re@-supported images soon - by 10.1 if not by 10.0), but = ARM EABI Hard-Float (the platform in question) is already supported by = clang and so has the same level of support as x86. =20 So let's be absolutely clear what we mean by non-x86: - Old ARM (ARMv4/ARMv5), most commonly used in microcontrollers which = don't have the power to run a full base system or arbitrary ports = anyway. =20 - MIPS, which is a few months of effort in LLVM to get completely = working. LLVM on MIPS is already self-hosting and I'm currently chasing = the remaining issues. We are planning on releasing an open source = MIPS64 implementation soon, and gcc will be the system compiler for the = first release, but we'll be switching to clang very soon for that - long = before 10.x goes EOL. MIPS has other serious issues (for example, gdb = doesn't work at all - it can't even find the memory regions that contain = the binary) and our ld is too old to support several of the GOT-related = optimisations required to build large programs, so gcc is the least of = its concerns, toolchain-wise. The MIPS binutils changes have not been = upstreamed, so this is somewhat problematic as we don't have any useable = toolchains for MIPS64, including gcc in base, for moderately-sized = applications. This should be addressed some time over the next 6-12 = months by switching MIPS over to LLVM / MCLinker. MIPS is perhaps the = most important one because the new owners of MIPS are investing in LLVM = quite heavily (they've been ramping up their LLVM development a lot over = the last year even before the purchase) and so it's important for us to = send a message to downstream FreeBSD/MIPS vendors that now is the time = to start thinking about switching toolchains. - PowerPC, which is a curiosity on old Apple hardware and is largely = used in embedded (mostly automotive?) applications beyond that. ANL = people are working hard on PowerPC 64 support for things like = BlueGene/Q, and PowerPC 32 is slowly coming along, although I think it's = missing a couple of things related to thread-local storage. For low-end = PowerPC32 embedded systems, most of the comments about ARMv4/5 apply. = For PowerPC64 - SPARC, which is effectively dead thanks to Oracle - Itanium, which is effectively dead thanks to Intel failing to learn = from their own mistakes By the way, I strongly resent the implication that I don't care about = non-x86 platforms, as I personally work on MIPS64 toolchain support and = have regular meetings with people at ARM about support there. >> Last but not quite least, people keep complaining about = ever-increasing=20 > build times and the size of the base system. Building a gcc and = libstdc++ by=20 > default every time, that we're telling people not to use, won't help = with=20 > that... >=20 > This is your worst argument as clang is known to take far longer than = GCC > to build. :) Not really. Clang + gcc takes longer to build than just clang. We can = also do a lot to fix clang build times by fixing our build systems to = properly expose the parallelism intrinsic in the build. I can build = LLVM+clang on my laptop in under 10 minutes with the upstream build = system, but doing it in the buildworld takes significantly longer. On a = 24-core system, it's under 3 minutes with the upstream build system, but = as long as on my laptop with ours. =20 > I posit that it only saves you work if you short-change non-x86 = platforms, > and that this will be harder to detect without gcc built on x86. I do = think > there is a decent chance that non-clang platforms will be more = aggressively > abandoned as a result of this change. By the end of the 10.x series, I expect non-clang platforms to be = SPARC64 and IA64. I don't think they need any help being abandoned - = their manufacturers seem to be facilitating this quite competently = without any assistance.=20 > Don't get me wrong, I don't love GCC per se, and on my laptop I've = hacked > the relevant ports so that everything is built with clang. I would = also > love to be able to build the base system with GCC 47 instead of 42, it = just > doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally = raised over a year ago, or at any of the points when it's been discussed = in between. It is not after we're ready to flip the switch. David From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 07:35:20 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30DDA6D8; Fri, 30 Aug 2013 07:35:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F169B2D32; Fri, 30 Aug 2013 07:35:19 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7U7ZG4Y007305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 07:35:18 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <52204746.2070900@freebsd.org> Date: Fri, 30 Aug 2013 08:35:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:35:20 -0000 On 30 Aug 2013, at 08:18, Julian Elischer wrote: > As far as I'm concerned we can even slate it for > "possible removal in 10.2-- if clang has proven up to the task" I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point = in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is = phenomenal). David From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 07:56:38 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3B01234; Fri, 30 Aug 2013 07:56:38 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBA872EF8; Fri, 30 Aug 2013 07:56:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7U7uZVs066226; Fri, 30 Aug 2013 07:56:36 GMT (envelope-from jonathan@FreeBSD.org) Date: Fri, 30 Aug 2013 08:56:35 +0100 From: Jonathan Anderson To: David Chisnall Message-ID: <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> Subject: Re: GCC withdraw X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: FreeBSD Current , Boris Samorodov , toolchain@freebsd.org, "=?utf-8?Q?freebsd-current=40freebsd.org_CURRENT?=" , "Sam Fourman Jr." , Julian Elischer X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:56:39 -0000 On Friday, 30 August 2013 at 08:35, David Chisnall wrote: > I would be happy to ship gcc, as long as: > > - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. > - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. I don't see how that's very different from requiring a gcc/g++ package. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 07:59:15 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2DF6D3C8; Fri, 30 Aug 2013 07:59:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB73B2F26; Fri, 30 Aug 2013 07:59:14 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7U7xBlG007438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 07:59:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> Date: Fri, 30 Aug 2013 08:59:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> To: Jonathan Anderson X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:59:15 -0000 On 30 Aug 2013, at 08:56, Jonathan Anderson = wrote: > Wouldn't this mean that we can't build base using the shipped-in-base = g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work = with libc++, then people wanting to compile the base system with gcc/g++ = will have to install a libstdc++ package. People wanting to build base with g++ will still have to explicitly = enable the build of libstdc++, yes. That's only really an issue for = 10.0 though, because in 10.1 we won't be able to build clang (or lldb) = with either g++ from base or our libstdc++ from base, as both use C++11 = features. David From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 13:38:51 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E0A6267; Fri, 30 Aug 2013 13:38:51 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B1042597; Fri, 30 Aug 2013 13:38:50 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7UDchn0056534; Fri, 30 Aug 2013 13:38:43 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qqzce2hvvfj8ufc7u4pem92s52; Fri, 30 Aug 2013 13:38:43 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Tim Kientzle In-Reply-To: <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> Date: Fri, 30 Aug 2013 06:38:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87CD56E4-98CE-4BA4-A9C6-433F9196A5B4@kientzle.com> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov , Jonathan Anderson X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:38:51 -0000 I've been reading this thread and must confess that I'm a little = confused about what exactly is being discussed. * I presume we've all agreed that "clang" is installed by default in = FreeBSD-10. * I presume everyone agrees that "cc" is "clang" in FreeBSD-10. * There obviously needs to be a "gcc" command in FreeBSD-10, since "cc" = and "gcc" are synonyms in so many people's finger-memory. Is the debate here just a question of whether "gcc" is "clang" or "the = *real* GCC"? Would it be feasible to install GCC as "gcc42" or something similar so people could still reach it regardless of what the "gcc" alias pointed to? On 30 Aug 2013, at 08:56, Jonathan Anderson = wrote: > ... then people wanting to compile the base system with gcc/g++ ... I'm still curious *why* some people want this? Personally, I would rather compile the base system with the *supported* compiler. Today, on FreeBSD-CURRENT/x86 and FreeBSD-CURRENT/amd64, that is clang. On Aug 30, 2013, at 12:18 AM, Julian Elischer = wrote: > Clang is new. clang WILL HAVE BUGS. Based on my own experience, I would put this rather differently: GCC and Clang are COMPILERS. Therefore, they have DIFFERENT BUGS. This is why I worry about having "cc" and "gcc" be different compilers. Tim From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 13:39:53 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B24B03D5 for ; Fri, 30 Aug 2013 13:39:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6C825B3 for ; Fri, 30 Aug 2013 13:39:53 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id 16so2813136iea.1 for ; Fri, 30 Aug 2013 06:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OZIkKJPVckF1Mb2YcBxCGDAHqDJi/revzQxAcw4LoX8=; b=SssjFLyXNUOHktuhq5L7egVu82ZiQyovgrLdu3OGeJtpmWj6BTAqvx8QwU1oBC4H4k CbjNu8j5MNHQBRk3CpnGw6WF5S80cKFWvifg406cfZXWseV+sYiTA2KKc0ZRy7U7KANE MEp8p8jaaFVKKLbkkymK4wx9Gx119cRofT0TAkIvM+zfj8KZpJQOrpfSHci6zHBUFTkn a+RJc7mr/LygjmM/RwabCplkAZIM5YMi2vHRri9zoyAxtLqPMoH4q7uZzyz2DD4tuCVz S7m6ozd8Fsr+uU9LHMb50ItA74q26LNMkKd/Rw3YPRrW5k+7eZnyVD6EfpdyWez7FR4w YL7w== X-Gm-Message-State: ALoCoQnvxBSwbauMS2kPKHHAKS6kHKbVtNN3JMt43qjl9H35e5Ds+f9mfhiCXDNjZmSadEkoyGTD X-Received: by 10.50.115.103 with SMTP id jn7mr6150223igb.1.1377869992695; Fri, 30 Aug 2013 06:39:52 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id x6sm3978623igb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 06:39:51 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 30 Aug 2013 07:39:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , John Baldwin , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:39:53 -0000 I had a long, rambling reply to this that corrected many of the factual = errors made in it. But why bother. You have your world view, it doesn't = match what people are doing today and this mismatch is going to cause = people pain and suffering in the embedded world far beyond what you = think. And you've shown an extreme reluctance to accept that your world = view isn't quite right, and listen to people. This makes me sad, but I = recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. = And it won't keep me from saying I told you so when your optimistic = timelines don't come to fruition, or the people processors you dismiss = as being too weak to run a full FreeBSD (despite the fact they are doing = it today) complain about the needless pain they are going through. Warner From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 13:47:29 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 929867D6; Fri, 30 Aug 2013 13:47:29 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 630672641; Fri, 30 Aug 2013 13:47:29 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VFP2o-000KcQ-32; Fri, 30 Aug 2013 13:47:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7UDlIuI057047; Fri, 30 Aug 2013 07:47:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182YgFMbhY83L8ziagawriK Subject: Re: GCC withdraw From: Ian Lepore To: Warner Losh In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Aug 2013 07:47:18 -0600 Message-ID: <1377870438.1111.311.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:47:29 -0000 On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: > I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. > > Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. > > Warner Actually, I have to put a +1 on this. I also had a long reply full of reality-based refutations of various "facts" from this thread, and I also just deleted it because clearly the discussion has become pointless. -- Ian From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 14:41:32 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61824EC5; Fri, 30 Aug 2013 14:41:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EB182A1E; Fri, 30 Aug 2013 14:41:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC2ACB939; Fri, 30 Aug 2013 10:41:30 -0400 (EDT) From: John Baldwin To: David Chisnall , Boris Samorodov Subject: Re: GCC withdraw Date: Fri, 30 Aug 2013 10:41:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308301041.18874.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Aug 2013 10:41:30 -0400 (EDT) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:41:32 -0000 Only a few comments in reply to avoid banging my head against a brick wall and then I'm done: On Friday, August 30, 2013 3:33:21 am David Chisnall wrote: > On 29 Aug 2013, at 18:44, John Baldwin wrote: > > Also, unless you plan on desupporting all non-x86 platforms, you _still_ > > have to do all this work while those platforms require GCC anyway. Just > > turning off GCC on x86 doesn't change this problem one iota. And that point > > is actually relevant to many of the other concerns you raised. It's not at > > all clear what disabling GCC on x86 will buy you unless you are intending on > > short-changing support for GCC on non-x86. > > It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. > [snip] So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. > > Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked > > the relevant ports so that everything is built with clang. I would also > > love to be able to build the base system with GCC 47 instead of 42, it just > > doesn't seem that we are there yet. > > The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say "Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86". Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? -- John Baldwin From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 14:46:26 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 53C151F1; Fri, 30 Aug 2013 14:46:26 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D80AC2A73; Fri, 30 Aug 2013 14:46:25 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so1946326obc.7 for ; Fri, 30 Aug 2013 07:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=v5ywJ4sQcWV4PVkH9vjeVOYcjgBPZHFQ4FlpuvDXbx0=; b=yQeEuoYqBSBpmEfaIIQ3yEmxjlWQPsvYj9DOSaQnR9hmqpRlrtgLIBWoEQSDc24cBQ wNxasBI6Ek6vtmd6Or6g/5OQX/VlM4VUuioFZ4qx1sYwvDCWAsW9AXQxY20ASzbFTJaY uQYGVpbD7FrCB8IAzl9Ev5Nf99/4xlUePoxGktdkYMKT3thZwCkMLFjUHYkXD/GGJiIa v+iQQgkDThZjYoKPFdr3aOeJMAax5eA5cmKla/h96ZW8yQKEuZGT549fVuclmEaxPd+2 COYcP/BHCeqPbdefJFI/pBZxhzGFRFAEpvI4LI3ymd23hx7iu4kTFjEH1QmwdBmIt0sB 6knw== MIME-Version: 1.0 X-Received: by 10.60.62.4 with SMTP id u4mr7137857oer.35.1377873985129; Fri, 30 Aug 2013 07:46:25 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.75.9 with HTTP; Fri, 30 Aug 2013 07:46:24 -0700 (PDT) In-Reply-To: <1377870438.1111.311.camel@revolution.hippie.lan> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> <1377870438.1111.311.camel@revolution.hippie.lan> Date: Fri, 30 Aug 2013 07:46:24 -0700 X-Google-Sender-Auth: VQnbYfaYNnDZUZk8khUeo6uiIQI Message-ID: Subject: Re: GCC withdraw From: Matthew Fleming To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , toolchain@freebsd.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:46:26 -0000 On Fri, Aug 30, 2013 at 6:47 AM, Ian Lepore wrote: > On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: > > I had a long, rambling reply to this that corrected many of the factual > errors made in it. But why bother. You have your world view, it doesn't > match what people are doing today and this mismatch is going to cause > people pain and suffering in the embedded world far beyond what you think. > And you've shown an extreme reluctance to accept that your world view isn't > quite right, and listen to people. This makes me sad, but I recognize a > lost cause when I see it. > > > > Do whatever the fuck you want, but it won't make your arguments right. > And it won't keep me from saying I told you so when your optimistic > timelines don't come to fruition, or the people processors you dismiss as > being too weak to run a full FreeBSD (despite the fact they are doing it > today) complain about the needless pain they are going through. > > > > Warner > > Actually, I have to put a +1 on this. I also had a long reply full of > reality-based refutations of various "facts" from this thread, and I > also just deleted it because clearly the discussion has become > pointless. I don't really have any skin in this game; the vendor I work for uses x86 hardware, and we're not ready to be running on FreeBSD 10 yet. But as an "old guy" I really don't see why we'd change the plan of record so late. Nor do I think prioritizing ports over the base system on alternate architectures is the right play -- there's a lot of vendors who use FreeBSD on !x86. And there's a lot of vendors who don't use very many ports. And there's a lot of vendors putting money into the FreeBSD foundation, and into the hands of FreeBSD committers, to make it better. Vendors who, while it would be painful to switch, do have a choice of which OS to build their product around. Just my 2c. Actual value may differ. Cheers, matthew From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 14:53:44 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B371B682; Fri, 30 Aug 2013 14:53:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83C1D2AF1; Fri, 30 Aug 2013 14:53:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MSC00900MK1M800@smtpauth2.wiscmail.wisc.edu>; Fri, 30 Aug 2013 09:53:43 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.8.30.144215, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (172-12-164-50.lightspeed.wlfrct.sbcglobal.net [172.12.164.50]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MSC009BKMPG8530@smtpauth2.wiscmail.wisc.edu>; Fri, 30 Aug 2013 09:53:42 -0500 (CDT) Message-id: <5220B1F3.1030807@freebsd.org> Date: Fri, 30 Aug 2013 07:53:39 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 To: David Chisnall Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> In-reply-to: X-Enigmail-Version: 1.5.1 Cc: FreeBSD Current , Boris Samorodov , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Julian Elischer X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:53:44 -0000 On 08/30/13 00:35, David Chisnall wrote: > On 30 Aug 2013, at 08:18, Julian Elischer wrote: > >> As far as I'm concerned we can even slate it for >> "possible removal in 10.2-- if clang has proven up to the task" > I would be happy to ship gcc, as long as: > > - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. > - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). > So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. -Nathan From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 14:55:46 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCDC57DF; Fri, 30 Aug 2013 14:55:46 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7A2D2B17; Fri, 30 Aug 2013 14:55:46 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7UEtima009547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 14:55:45 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <5220B1F3.1030807@freebsd.org> Date: Fri, 30 Aug 2013 15:55:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <5220B1F3.1030807@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:55:46 -0000 On 30 Aug 2013, at 15:53, Nathan Whitehorn = wrote: > So the real driver here is switching to libc++. Is there really no way > at all to use it with gcc? If, even with hacking, we could arrange = that > to work then it seems that all of our problems would go away. If we can make our g++ compile C++11 code, then we can compile libc++ = with g++. This support requires significant modifications to the parser = (it adds a second Turing-complete compile-time language, for one...) and = so retrofitting C++11 support to g++ 4.2.1 is not going to happen. It's = taken upstream gcc a couple of years to get to the required level of = support. We don't have the manpower to replicate this. David From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 15:11:12 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0376C01; Fri, 30 Aug 2013 15:11:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A268F2BFE; Fri, 30 Aug 2013 15:11:11 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7UFB816009699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 15:11:10 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308301041.18874.jhb@freebsd.org> Date: Fri, 30 Aug 2013 16:11:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:11:12 -0000 On 30 Aug 2013, at 15:41, John Baldwin wrote: > So my take away from this is that you have no plans to support any = platform that > doesn't support clang as you just expect ia64 and sparc64 to die and = not be > present in 11.0. That may be the best path, but I've certainly not = seen that > goal discussed publically. I expect that platforms that don't have support from clang or some = external toolchain will die. If people care about IA64, then getting = Intel's compiler working as an external toolchain would probably be a = good idea (it generates vastly better code than gcc). If people care = about SPARC64, then either gcc from ports as an external toolchain, or = finishing up the SPARC64 back end in LLVM are options. Finishing the = SPARC64 back end is not that much effort (it's probably a couple of = person-months of work - getting the calling conventions right does = require some small tweaks to LLVM IR that I think someone's working on), = but it hasn't been done because no one appears to care quite enough to = make it a priority. >>> Don't get me wrong, I don't love GCC per se, and on my laptop I've = hacked >>> the relevant ports so that everything is built with clang. I would = also >>> love to be able to build the base system with GCC 47 instead of 42, = it just >>> doesn't seem that we are there yet. >>=20 >> The time to raise objections for this was when the plan was = originally raised over a year ago, or at any of the points when it's = been discussed in=20 > between. It is not after we're ready to flip the switch. >=20 > So I think the crux of the issue might be this: >=20 > I have no doubt that this has been discussed extensively on toolchain@ = and in > toolchain-specific devsummit sessions. The proposal to disable GCC by = default > does not appear to have been discussed in a wider audience from what I = can > tell. (I can't find any relevant threads on arch@ or current@ prior = to this > one.) While this is a toolchain-specific decision, it is a very broad > decision. Also, we aren't here because of a new thread started = intentionally > to say "Hey, we as the toolchain folks think we should disable GCC by = default > on 10 for x86". Instead, we started off in a thread about adding AES > instructions to our binutils and out of left field there is an e-mail = of > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). = Can you > appreciate at all that this is a total surprise to people who aren't > subscribed to toolchain@ and haven't been to a toolchain session at a=20= > devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the = impression that this was widespread common knowledge and something I've = personally discussed with various people including ports people on = several occasions. I would have made the commit a couple of months ago, = but getting the ports infrastructure back up to a state where it's easy = to test has been a blocker there. =20 If removing gcc from the standard install is going to cause major pain = for people, then we can leave it in for 10.0. I'm currently doing a = make tinderbox on the removal patch, modified to leave gcc in, and only = remove libstdc++, which is something that we definitely need to do = because it's causing an amount of pain that is only going to increase. = I have no plans to make anything in the base system (other than clang = itself, when 3.4 is imported) depend on libc++-only features (I'd love = to do it for dtc, but it has to run on embedded platforms that are going = to be stuck with libstdc++ in base for a while - at least a year, and = that's if we're lucky). =20 Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so = here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the = default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've = already agreed not to commit this part, since it seems very = controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting = the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the = WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system = compiler - On platforms where clang is not cc, leave libstdc++ as the default = system STL, but encourage ports to start depending explicitly on = ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are = free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then = you are free to install it, clang will still use it if you specify = -stdlib=3Dlibstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you = will see no difference. If you need to test whether building the base system or kernel with gcc = fixes things that are broken, then you are free to build = WITHOUT_CLANG_IS_CC and WITH_GCC and test it (or set WITH_GCC, install, = and then use XCC to use the installed gcc for testing. Or install one = of the lang/gcc ports and use XCC for testing). In the medium term, = this should continue to work until there is some compelling reason for = it to be broken (which is the topic of a future discussion, where I = would expect very compelling reasons to be required). =20 I am not proposing: - To delete gcc from the tree - To delete libstdc++ from the tree - To deprecate any architectures - To break any architectures - To commit loads of C++11 / C11 code to the base system and break the = build with gcc - To rely on any clang-specific extensions in base-system code - To remove anything from cdefs.h that allows stuff to work with gcc - To set fire to your cat David From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 15:40:02 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B74E768; Fri, 30 Aug 2013 15:40:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58DCE2D87; Fri, 30 Aug 2013 15:40:02 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7UFdwQx087822; Fri, 30 Aug 2013 08:39:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7UFdwul087821; Fri, 30 Aug 2013 08:39:58 -0700 (PDT) (envelope-from sgk) Date: Fri, 30 Aug 2013 08:39:58 -0700 From: Steve Kargl To: Tim Kientzle Subject: Re: GCC withdraw Message-ID: <20130830153958.GA87788@troutmask.apl.washington.edu> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> <87CD56E4-98CE-4BA4-A9C6-433F9196A5B4@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87CD56E4-98CE-4BA4-A9C6-433F9196A5B4@kientzle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov , Jonathan Anderson X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:40:02 -0000 On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote: > > On 30 Aug 2013, at 08:56, Jonathan Anderson wrote: > > > ... then people wanting to compile the base system with gcc/g++ ... > > > I'm still curious *why* some people want this? > Buildworld completes in 1/4th the amount of time with gcc and it consumes much less memory. -- Steve From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 15:47:18 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4848943; Fri, 30 Aug 2013 15:47:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FECE2E06; Fri, 30 Aug 2013 15:47:18 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7UFlE8v087868; Fri, 30 Aug 2013 08:47:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7UFlEhh087867; Fri, 30 Aug 2013 08:47:14 -0700 (PDT) (envelope-from sgk) Date: Fri, 30 Aug 2013 08:47:14 -0700 From: Steve Kargl To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130830154714.GB87788@troutmask.apl.washington.edu> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , John Baldwin , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:47:18 -0000 On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote: > On 29 Aug 2013, at 18:44, John Baldwin wrote: > > > default every time, that we're telling people not to use, won't help with > > that... > > > > This is your worst argument as clang is known to take far longer than GCC > > to build. :) > > Not really. Clang + gcc takes longer to build than just clang. Building gcc is in the noise. I've sent you number on this. John is correct. It takes much much longer to buildworld with clang. -- Steve From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 16:05:03 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B57981D7; Fri, 30 Aug 2013 16:05:03 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38DC82F1B; Fri, 30 Aug 2013 16:05:03 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ij15so1479026vcb.30 for ; Fri, 30 Aug 2013 09:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XjCz5mN5/pHYNAP2gIxsEbQdDcWydOa6Iu4PILbXHNI=; b=S6jNpCMxBgoXPJgV4vkSLfGZPblL3Sde8EZGYBzf21RpKb3UmRs0EwMRAuuZ+vpOvi L+8UcJXOXxwuUc9pB5QYYkaTPnvC/s72L6gfOrKvzGHkgLLaMTKSzPwWUZXrYbXUFRbn 1PTS5sOGuBRSBHcqR5Y4MBGeXT4yiv9W8yTdecNrPsl5PIJe7rtCH+L+pTjV1UGge+o4 J8yeerow4YQNZ9DIX74LZRLBIcAHYmO/xMM+RamNwWhLazlC0NJMyOWfsiEWS6sVqW/l Pjd6oVWlRtYFdPiqd0eGeHXuzSGaPzi77LSzdPT2qTzMDkNF02HWEtLWWPUOUZl526gu rVXA== MIME-Version: 1.0 X-Received: by 10.220.75.73 with SMTP id x9mr162392vcj.38.1377878702316; Fri, 30 Aug 2013 09:05:02 -0700 (PDT) Received: by 10.58.118.104 with HTTP; Fri, 30 Aug 2013 09:05:02 -0700 (PDT) In-Reply-To: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> Date: Fri, 30 Aug 2013 12:05:02 -0400 Message-ID: Subject: Re: GCC withdraw From: Mehmet Erol Sanliturk To: David Chisnall Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , John Baldwin X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:05:03 -0000 On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall wrote: > On 30 Aug 2013, at 15:41, John Baldwin wrote: > > > So my take away from this is that you have no plans to support any > platform that > > doesn't support clang as you just expect ia64 and sparc64 to die and not > be > > present in 11.0. That may be the best path, but I've certainly not seen > that > > goal discussed publically. > > I expect that platforms that don't have support from clang or some > external toolchain will die. If people care about IA64, then getting > Intel's compiler working as an external toolchain would probably be a good > idea (it generates vastly better code than gcc). If people care about > SPARC64, then either gcc from ports as an external toolchain, or finishing > up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back > end is not that much effort (it's probably a couple of person-months of > work - getting the calling conventions right does require some small tweaks > to LLVM IR that I think someone's working on), but it hasn't been done > because no one appears to care quite enough to make it a priority. > > >>> Don't get me wrong, I don't love GCC per se, and on my laptop I've > hacked > >>> the relevant ports so that everything is built with clang. I would > also > >>> love to be able to build the base system with GCC 47 instead of 42, it > just > >>> doesn't seem that we are there yet. > >> > >> The time to raise objections for this was when the plan was originally > raised over a year ago, or at any of the points when it's been discussed in > > between. It is not after we're ready to flip the switch. > > > > So I think the crux of the issue might be this: > > > > I have no doubt that this has been discussed extensively on toolchain@and in > > toolchain-specific devsummit sessions. The proposal to disable GCC by > default > > does not appear to have been discussed in a wider audience from what I > can > > tell. (I can't find any relevant threads on arch@ or current@ prior to > this > > one.) While this is a toolchain-specific decision, it is a very broad > > decision. Also, we aren't here because of a new thread started > intentionally > > to say "Hey, we as the toolchain folks think we should disable GCC by > default > > on 10 for x86". Instead, we started off in a thread about adding AES > > instructions to our binutils and out of left field there is an e-mail of > > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can > you > > appreciate at all that this is a total surprise to people who aren't > > subscribed to toolchain@ and haven't been to a toolchain session at a > > devsummit and that this looks like a drive-by change? > > Yes, we certainly could have communicated this better. I was under the > impression that this was widespread common knowledge and something I've > personally discussed with various people including ports people on several > occasions. I would have made the commit a couple of months ago, but > getting the ports infrastructure back up to a state where it's easy to test > has been a blocker there. > > If removing gcc from the standard install is going to cause major pain for > people, then we can leave it in for 10.0. I'm currently doing a make > tinderbox on the removal patch, modified to leave gcc in, and only remove > libstdc++, which is something that we definitely need to do because it's > causing an amount of pain that is only going to increase. I have no plans > to make anything in the base system (other than clang itself, when 3.4 is > imported) depend on libc++-only features (I'd love to do it for dtc, but it > has to run on embedded platforms that are going to be stuck with libstdc++ > in base for a while - at least a year, and that's if we're lucky). > > Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so > here's an executive summary of what I'm ACTUALLY proposing: > > - On platforms where clang is cc, don't build libstdc++, make libc++ the > default. Provide libstdc++ from base as a 9-compat package. > > - On platforms where clang is cc, don't build gcc by default (I've already > agreed not to commit this part, since it seems very controversial, although > I'd like to better understand why it is so) > > - On platforms where clang is cc, allow building libstdc++ by setting the > WITH_GNUCXX flag > > - On platforms where clang is cc, allow building gcc by setting the > WITH_GCCflag > > - On platforms where clang is not cc, leave gcc as the default system > compiler > > - On platforms where clang is not cc, leave libstdc++ as the default > system STL, but encourage ports to start depending explicitly on > ports-libstdc++ so that they don't suffer from ABI mismatch issues. > > If your workflow depends on gcc on a clang-is-cc platform, then you are > free to install it. > If your workflow depends on libstdc++ on a clang-is-cc platform, then you > are free to install it, clang will still use it if you specify > -stdlib=libstdc++. > If your workflow depends on gcc or libstdc++ on any other platform, you > will see no difference. > If you need to test whether building the base system or kernel with gcc > fixes things that are broken, then you are free to build > WITHOUT_CLANG_IS_CC and WITH_GCC and test it (or set WITH_GCC, install, and > then use XCC to use the installed gcc for testing. Or install one of the > lang/gcc ports and use XCC for testing). In the medium term, this should > continue to work until there is some compelling reason for it to be broken > (which is the topic of a future discussion, where I would expect very > compelling reasons to be required). > > I am not proposing: > > - To delete gcc from the tree > > - To delete libstdc++ from the tree > > - To deprecate any architectures > > - To break any architectures > > - To commit loads of C++11 / C11 code to the base system and break the > build with gcc > > - To rely on any clang-specific extensions in base-system code > > - To remove anything from cdefs.h that allows stuff to work with gcc > > - To set fire to your cat > > David > > To be able to compile a source tree with different compilers is an important "Code Review Process" with the assumption that the source code is written exactly to adhere a standard and not using any extension of the used compilers ( if there are absolute necessity to use extensions such as "date" , "time" , etc . , these are collected into common routines ) . It is obvious that no any "human" expert can review a source tree like a "compiler" expert . A compiler may be considered an "expert" because expertise of programmers are transferred into it as much as possible . For this process , it is not important which compiler is selected for "production" release . This depends on goals of releases . For development and testing , many compilers may be used and their outputs may be compared . I am doing this for Fortran and Pascal . With respect to my experiences , to rely on a single compiler for any source tree is really a very UNRELIABLE programming practice . Sometimes , some compilers are producing very erroneous code . These cases are requiring special attention : By using also theoretical programming "human" expertise , these may be results of the following : Some parts of the source are not conforming to standards . There are some bugs which they are not recognized by other compilers . Messages during compilations are not sufficiently produced to inform about possible erroneous points . Some compilers are generating code which is not tracking run time exceptions . Some compilers at some special source statement combinations are producing erroneous code . Using different compilers are detecting such problems much easier than human programmers . Now , I am not able to think to write a program without using different compilers to test its outputs . By based on such experiences , my strong suggestion is that "Use as many compilers as possible ( even commercially available compilers if there exist some ) for the FreeBSD source tree after selecting a standard during development and testing ." This is the cheapest and most reliable "Code Review Process" . "Use a suitable compiler for the FreeBSD Project during releases ." Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 19:00:26 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4A05A597 for ; Fri, 30 Aug 2013 19:00:26 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98FD728AC for ; Fri, 30 Aug 2013 19:00:25 +0000 (UTC) Received: from mail-wg0-f50.google.com ([74.125.82.50]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKUiDrwsClUl0umA8ICwthfvnhtK4ZIN5K@postini.com; Fri, 30 Aug 2013 19:00:25 UTC Received: by mail-wg0-f50.google.com with SMTP id m14so1908915wgh.17 for ; Fri, 30 Aug 2013 12:00:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=3+QqOpA7NU6/Dg62hwuwNHs5mg5ZHN2l59pNQL6r5G0=; b=aA55axkwd6f/6v9sT9okXwVtmgvziH4nw8yLnqvRJYdBZyPfTaEe2xKCNaLz0f6Myh 5s/GdcMJQqvSIRr+/KQFSfngEwGtf5iM77xhEqdfa1VeWxJhWyNTLy0xxsbdU84zKA24 5sO28u4n4qrw3X++h5Jqz23QozEKkwr+pLdZrERx1mbxydf+6dICBHmftWpk4QG4wzg9 aFS3+eBYe0aeIogE5LRKf1vrA9uQ7tlcGdDWhCiKJGy3fuQ3frqki5KiAb3g3z5ivCLn Lnf7ddlrnWaEAo/9r7nkKM8bxoKdmHDJEe8KTQR00u5SpLNMy+st9dJ4+M+TVlnO3Cg3 BvVg== X-Received: by 10.180.75.205 with SMTP id e13mr3645715wiw.29.1377888830226; Fri, 30 Aug 2013 11:53:50 -0700 (PDT) X-Gm-Message-State: ALoCoQlQFAkwzgUiaZczH86AoYr3dEGr009/w/xazAnPqTLHsUJFb9tYi6IQiTnATwhSaJE+E51qcJ/IiEMN1M6/GI54evM3x17pptEsx6EMjRsyPzw32oTD7OMnnBi45+DWF4Bhx6KicUlWgwsyb7Gbc2I0ipylCA0SSZS9q2H86X/ecfvpdro= X-Received: by 10.180.75.205 with SMTP id e13mr3645700wiw.29.1377888830096; Fri, 30 Aug 2013 11:53:50 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id o9sm6350816wiz.1.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 11:53:49 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r7UIrkEv026487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Aug 2013 19:53:47 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r7UIrkkg026486; Fri, 30 Aug 2013 19:53:46 +0100 (BST) (envelope-from mexas) Date: Fri, 30 Aug 2013 19:53:46 +0100 (BST) From: Anton Shterenlikht Message-Id: <201308301853.r7UIrkkg026486@mech-cluster241.men.bris.ac.uk> To: imp@bsdimp.com, jhb@FreeBSD.org Subject: Re: GCC withdraw In-Reply-To: Cc: current@freebsd.org, toolchain@freebsd.org, freebsd-current@freebsd.org, sfourman@gmail.com, bsam@passap.ru X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:00:26 -0000 >Subject: Re: GCC withdraw >From: Warner Losh >Date: Thu, 29 Aug 2013 10:00:19 -0600 > Gcc is still an absolute requirement on all non-x86 platforms (including arm) due to the issues with clang. Some of these issues are bugs in specific things (arm) that keep coming up (and keep getting fixed), while others are more severe (sparc64 has no clang support, and don't forget ia64 Anton From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 30 19:20:07 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6DD93935; Fri, 30 Aug 2013 19:20:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2319D2971; Fri, 30 Aug 2013 19:20:06 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFUGk-0005TP-Dz; Fri, 30 Aug 2013 23:22:06 +0400 Date: Fri, 30 Aug 2013 23:22:06 +0400 From: Slawa Olhovchenkov To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130830192206.GA20439@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current , John Baldwin X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:20:07 -0000 On Fri, Aug 30, 2013 at 04:11:08PM +0100, David Chisnall wrote: > Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: > > - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. > > - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) And remember about breaking firewire+clang From owner-freebsd-toolchain@FreeBSD.ORG Sat Aug 31 07:33:32 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05C82CAD; Sat, 31 Aug 2013 07:33:32 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CFB222096; Sat, 31 Aug 2013 07:33:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7V7XUTI061470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Aug 2013 00:33:30 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7V7XUEg061469; Sat, 31 Aug 2013 00:33:30 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 Aug 2013 00:33:30 -0700 From: John-Mark Gurney To: John Baldwin Subject: Re: GCC withdraw Message-ID: <20130831073330.GC36239@funkthat.com> Mail-Followup-To: John Baldwin , David Chisnall , Boris Samorodov , "Sam Fourman Jr." , toolchain@freebsd.org, FreeBSD Current References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201308301041.18874.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 Aug 2013 00:33:30 -0700 (PDT) Cc: "Sam Fourman Jr." , Boris Samorodov , FreeBSD Current , toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 07:33:32 -0000 John Baldwin wrote this message on Fri, Aug 30, 2013 at 10:41 -0400: > So I think the crux of the issue might be this: > > I have no doubt that this has been discussed extensively on toolchain@ and in > toolchain-specific devsummit sessions. The proposal to disable GCC by default > does not appear to have been discussed in a wider audience from what I can > tell. (I can't find any relevant threads on arch@ or current@ prior to this > one.) While this is a toolchain-specific decision, it is a very broad > decision. Also, we aren't here because of a new thread started intentionally > to say "Hey, we as the toolchain folks think we should disable GCC by default > on 10 for x86". Instead, we started off in a thread about adding AES > instructions to our binutils and out of left field there is an e-mail of > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can you > appreciate at all that this is a total surprise to people who aren't > subscribed to toolchain@ and haven't been to a toolchain session at a > devsummit and that this looks like a drive-by change? Why didn't this come up when John added XSAVE (a year ago) or Pedro Giffuni added amdfam10 support (3 months ago)? Plus, I've sent other patches earlier this year to -toolchain and made clear why I was adding them... Had I known that the policy was gcc was dead for HEAD (which btw, I was told multiple times that we were keeping gcc for 10 for i386/amd64), I would have just committed my kernel changes by now, but didn't want to break a (what I thought was) supported configuration... We need to communicate better on issues like these, since this isn't the first time one group of people made a decision w/o telling the rest of the community... For major items like this, we need to make sure the road map is published, either on www.freebsd.org or on the wiki and gets kept up to date... For example, the release schedule for 10 wasn't posted till over a week after the code slush was announced (which caught people, like myself, by surprise)... That's kinda the wrong order to do it in, the schedule should be posted well in advance so people know what to expect... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-toolchain@FreeBSD.ORG Sat Aug 31 07:52:42 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C040215; Sat, 31 Aug 2013 07:52:42 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 469712176; Sat, 31 Aug 2013 07:52:41 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7V7qcp0015616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 31 Aug 2013 07:52:40 GMT (envelope-from theraven@freebsd.org) Content-Type: multipart/signed; boundary="Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <20130831073330.GC36239@funkthat.com> Date: Sat, 31 Aug 2013 08:52:34 +0100 Message-Id: <98D31DD3-8A1D-46ED-9BF6-9EBE39640860@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <20130831073330.GC36239@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , John Baldwin X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 07:52:42 -0000 --Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 Aug 2013, at 08:33, John-Mark Gurney wrote: > Why didn't this come up when John added XSAVE (a year ago) or Pedro > Giffuni added amdfam10 support (3 months ago)? >=20 > Plus, I've sent other patches earlier this year to -toolchain and made > clear why I was adding them... Had I known that the policy was gcc = was > dead for HEAD (which btw, I was told multiple times that we were = keeping > gcc for 10 for i386/amd64), I would have just committed my kernel = changes > by now, but didn't want to break a (what I thought was) supported > configuration... gcc is not dead for 10.0, we're simply wanting to not ship it in binary = form by default. There is a BIG difference between saying 'if you want = gcc then you must explicitly opt in and build it yourself and it may not = be there for the entire 10.x series' and saying 'gcc is gone now, don't = expect any of FreeBSD to build with it'. We are absolutely not = proposing the latter for 10.0. =20 We still expect the 10.0 kernel and most of the userland (libc++ = excepted) to build with gcc. We expect this to be true for 10.1, and = probably 10.2, possibly even 10.3. I'd probably expect that at least = the kernel will build with gcc 4.2.1 for the entire timeframe. Some = modules may not, although for ease of debugging compiler bugs I'd = recommend that if they don't build with gcc 4.2.1 then at least they = build with upstream gcc. However, we want to be able to make it unsupported at some point in the = 10.x series when there is a polished alternative for every supported = architecture (either when they've moved to clang or when the XCC stuff = is fully documented in the handbook and tested in a large variety of = configurations and once our forked binutils and is available as a = package and we have cross-gcc that uses it). If this doesn't happen by = the time 10.x is EOL'd then I'll be sad, but we still have the fall-back = position of gcc in base for the entire 10.x. If it does happen, then we = can start more aggressively phasing out gcc in the base system. =20 > We need to communicate better on issues like these, since this isn't = the > first time one group of people made a decision w/o telling the rest > of the community... For major items like this, we need to make sure > the road map is published, either on www.freebsd.org or on the wiki = and > gets kept up to date... I agree. This is why I made sure that at the BSDCam DevSummit all of = the sessions had someone who was taking notes for their sessions on the = wiki: https://wiki.freebsd.org/201308DevSummit#Schedule-1 (Well, except, somewhat ironically, the docs team, who still haven't put = their notes on the wiki) It's also why I've taken charge of putting out special status reports = for each DevSummit for wider public consumption, like this one: http://www.freebsd.org/news/status/report-2013-05-devsummit.html I'd be interested in hearing any more suggestions about how we can = improve this. > For example, the release schedule for 10 wasn't posted till over a = week > after the code slush was announced (which caught people, like myself, = by > surprise)... That's kinda the wrong order to do it in, the schedule > should be posted well in advance so people know what to expect... This one you'll have to discuss with re@. I think that after 10.0 there = will be some more discussion about our release policy. =20 David --Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSIaDCAAoJEKx65DEEsqIddaIQAMoFVo3wnksWdRfZDNb0bDra hnga7Y6y02S3OVlHJUTtdvvLHTZC58lMSX1S3KHddbGYTgoirnpInPPd1Rqibq2X f980yOlvDksr8MqJvFdPRO7nxw/z+/iBhJaZlrwMJZ5MnZozZ9Lsr/EzRN9DdfaH aLBCWN7EjrYKJOaMPBH1nADYk8TfZw4iNLm18afSTAxd4hX1FHv5WivUsI869deg WQKk9Re5OuidQxl1Sc8c7Y0snXIK2OmNqmMXWjuKr+H2hLZN906lA6lrWxA5Ma4P NsoH/xPbK99dNAAjfA8L5uoqtempjAI8uerAuswbgf4kemwCeruwnvQl5cfsP5hd wcZ8EBkFYYKtonYtk8CTZ3d8cFkb++Rnxumc4DMbPIereeSA7oszIq6vbyewagft uDMtmg9fgP1u3aeJL8tTKXF0l0xTTa+kVRaOU3ahhT3/5VkAGPYZtbR9NuaX85Md 49HTe04u/kUKDNM8vSJCHE0EmAifAT1erEtjBaT8CQ49QlvpDsFtWeGKEQPL6KVv WIGhNfR9Cb/KzgfhLvTJ8a6MEtUTGBpdod0gEUvUtP2zWh84DpX+lDu135ZcvFPY Zok4qSE/2VK3J+wuq5ApFUH7NAXTnJrgTcyHdvKKGu1tWdnjYoDONrXKG4LFgcuD rxHM5svmJHs6TzqExqxo =er+m -----END PGP SIGNATURE----- --Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6--