Date: Fri, 30 Aug 2013 12:05:02 -0400 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: David Chisnall <theraven@freebsd.org> Cc: "Sam Fourman Jr." <sfourman@gmail.com>, toolchain@freebsd.org, Boris Samorodov <bsam@passap.ru>, FreeBSD Current <current@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: GCC withdraw Message-ID: <CAOgwaMuaHc1k3nApBh94XA=x%2Bnxm_Ej42%2BA%2B85sV-XougUta5g@mail.gmail.com> In-Reply-To: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <A981C965-D625-458B-B0AB-171C983AEA42@FreeBSD.org> <201308301041.18874.jhb@freebsd.org> <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall <theraven@freebsd.org>wrote: > On 30 Aug 2013, at 15:41, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMuaHc1k3nApBh94XA=x%2Bnxm_Ej42%2BA%2B85sV-XougUta5g>