llvm dev - Oct 2013 - [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

On 27 Oct 2013, at 09:31, Benjamin Kramer <benny.kra at gmail.com> wrote:
> - Freebsd 10 is on Clang/libc++ by default, FreeBSD 9 also shipped Clang.
Don't see problems here.
Note that this is only for x86 and ARM.  For PowerPC64 and MIPS, which look as
if they'll be supported by LLVM/Clang soon (we now have PowerPC64 working,
but the kernel must be compiled at -O0 or it doesn't boot, MIPS is still
quite buggy, but getting there), we're still shipping gcc 4.2.1.  These are
tier 2 platforms, so we could cross-compile the toolchain from x86 for
bootstrapping, but it would be quite painful.

David

Hi folks,

I'm up for it. I agree there are issues to work around for specific
distros, but this is dragging for far too long. The main reasons against it
until last year was: "this is not the standard yet", and
"compiler support
is patchy". I think we're past that, now.


On 27 October 2013 13:57, David Chisnall <David.Chisnall at
cl.cam.ac.uk>wrote:
> Note that this is only for x86 and ARM.  For PowerPC64 and MIPS, which
> look as if they'll be supported by LLVM/Clang soon (we now have
PowerPC64
> working, but the kernel must be compiled at -O0 or it doesn't boot,
MIPS is
> still quite buggy, but getting there), we're still shipping gcc 4.2.1.
>  These are tier 2 platforms, so we could cross-compile the toolchain from
> x86 for bootstrapping, but it would be quite painful.
>
Well, GCC 4.6 is going into maintenance mode, and there's a lot of work
going on 4.7+ for cross-compilation. If anything, driving this forward will
mean GCC will get better on these platforms because people will start to
report more problems with the newer versions. I think that shipping any
Unix variant with GCC 4.2 is, in its own, a much bigger problem than
anything we've been discussing so far, and needs to be tackled in separate.

It's what people are saying about Windows. If we stop any progress because
one specific platform has one specific self-inflicted problem, we'll never
move. As it has been said already, there's always the chance to get an
older LLVM (up to 3.4) and use that to compiler the newer LLVM.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/02f01870/attachment.html>