From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 16:05:03 2013 Return-Path: Delivered-To: current@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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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