Re: GCC withdraw

On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall <theraven_at_freebsd.org>wrote:

> On 30 Aug 2013, at 15:41, John Baldwin <jhb_at_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_at_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_at_ or current_at_ 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_at_ 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