On 8/30/13 1:02 AM, David Chisnall wrote:
On 29 Aug 2013, at 15:57, John Baldwin <j...@freebsd.org> 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
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
