From owner-freebsd-toolchain@FreeBSD.ORG Fri Aug 23 22:38:01 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 3A4166E8 for ; Fri, 23 Aug 2013 22:38:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F24C22944 for ; Fri, 23 Aug 2013 22:38:00 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wc20so1279159obb.28 for ; Fri, 23 Aug 2013 15:37:54 -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=fCa96hHT09vZYKsMml2pu3r0dMr5x18tp0uOx0IG7Ys=; b=OL/D2/nCu+Uf6Dtl6/Iu0uyPZxpmyIGyP4Kn2afqrgojKqdcnl5D0uajrS5BVxg1h6 GY+090LKxYPPT7LzH2aUFtsSvzOqrgvJ7gcHyZrdF105stHXh+RbJKhBy5yVsuKHp6+Q e1qQjKCnG2a4M++qnPUZg/ETwAsa4NvxXx+tUtJ3twnObD9H8mMYMWqQzdRNUYXzFpE8 20uNrpEylSJ8Wl7W9jjX6+GwZMezT7kBkTV8VEVzk806LwgHZBg8qyXiNtguxAVPXpEP eNQGxY/guY+J/fq18j5xzfMDqCgxoUO4Hyg5q/f7cDGto8dppBWfLFuDzVR9+wNWHeCu P+Dg== X-Gm-Message-State: ALoCoQmWT06/2jsMi1VxVtaN2mfPJeJWOmzLaU92DSbl9jHjZfxU67DpE/ZKVpeNltwImPu/VqSv X-Received: by 10.60.124.14 with SMTP id me14mr1745298oeb.4.1377297474066; Fri, 23 Aug 2013 15:37:54 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id qi5sm2052749obb.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 15:37:53 -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=iso-8859-1 From: Warner Losh In-Reply-To: <5217DBAB.5030607@freebsd.org> Date: Fri, 23 Aug 2013 16:37:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <86032E72-A569-4946-B4F8-26F687067B31@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> To: Alfred Perlstein X-Mailer: Apple Mail (2.1085) Cc: toolchain@FreeBSD.org, John-Mark Gurney , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 22:38:01 -0000 On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote: > On 8/23/13 3:35 AM, David Chisnall wrote: >> On 23 Aug 2013, at 10:58, Bernhard Fr=F6hlich = wrote: >>=20 >>> I don't know if you are aware that IF you really do that we will = have serious >>> problems to ship packages for 10. USE_GCC=3Dany is the fallback in = the >>> portstree for all ports that are unable to build with clang which = was introduced >>> when HEAD switched to clang as default cc. Right now there are 150 = ports in >>> the tree that use this fallback and quite a few of them are high = profile ports: >>>=20 >>> the highlights: >>> audio/nas devel/mingw32-binutils emulators/qemu = emulators/virtualbox-ose >>> emulators/wine lang/go lang/v8 mail/courier math/fftw3 = multimedia/libxine >>> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >>> security/clamav >>>=20 >>> the full list: >>> http://dpaste.com/1354075/ >>>=20 >>> A possible hack could be to add a check for USE_GCC=3Dany to behave = like >>> a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in = lang/gcc >>> from ports for a lot of people on HEAD I suppose. >>>=20 >>> We certainly need to do that switch to remove the ancient gcc from = base >>> some time but with my portmgr hat on I can only say we don't plan to = do that >>> before 10.0 especially not if we are only talking about a few weeks = time window. >> That is unfortunate. We have said for over a year that 10.0 should = not ship with gcc. I can delay committing the patch to flip the switch = until later in the code slush, if re approves, but ports that require = gcc should be building with gcc from ports (which will also improve code = quality, as gcc 4.6/7 produce significantly better code than 4.2.1). >>=20 >> David >>=20 >> _______________________________________________ >>=20 > Why can't ports just then add the old-version of GCC? This tight = coupling between src and ports is screwing us over for far too long. ports already has various gcc versions in ports, needed for dozens of = ports that require newer gcc, and this could be adopted for the gcc from = base issue. But that's not the issue. It is making the ports that need = it use it, and from the quoted message it sounds like that would take = work. Work takes time, and the window is closing. > If src needs to move on, and it surely seems like it does, then ports = needs to adapt. I'd dispute the 'and surely it seems like it does' part of this. Non x86 = architectures will continue to use gcc because clang just isn't ready at = this time for them. Some are very close (arm), some are close = (powerpc64, mips*), some are no where near ready, or will never be ready = (sparc64, ia64). There's no coherent, documented plan for these absent = gcc at the moment. There are lots of pieces there, and those pieces will = form the basis of the solution (+handbook updates) for the removal of = gcc in 11, but we just aren't there yet. > No offense to either team, but this is just common sense. The only ones that would really matter are ones in any bootstrap path we = might need for external toolchains. Since qemu is the basis for cross = building ports, it is disturbing to see that on the list. I know qemu = has, in the past, been sensitive to compiler versions, as are many of = the emulators in the tree. It might not be a simple matter to just use = gcc 4.6 or 4.7 for some of the items on the list. When I've moved gcc = versions and had problems with FOSS it is either due to new = warnings/errors and language violations. Some of these are trivial to = fix, others reveal fundamental flaws in the code and many changes are = needed. Sometimes newer compilers also have optimizations bugs (as = opposed to language violations now optimized differently) which break = things at run-time, despite things appearing to compile. These aren't = insurmountable problems, but do take time to implement and test. Warner