[LLVMdev] Using C++'11 language features in LLVM itself

Justin Holewinski justin.holewinski at gmail.com
Thu Jan 10 05:32:28 PST 2013

On Thu, Jan 10, 2013 at 1:11 AM, Pawel Wodnicki <root at 32bitmicro.com> wrote:

> Hello,
>  I have been following this discussion for a while and I think the
> question we should be asking is:
>  Why do we want to even bother with all these other broken C++
> compilers in a first place?

Because not everyone that uses LLVM also uses Clang for every C++ compile.
 If someone wants to use LLVM as their optimizer/code generator for a new
language, why restrict them to using Clang for their entire project.  This
is especially crucial in HPC applications, where you may want to use LLVM
to compile a domain-specific language and the compiler is part of a larger
project that you want to compile using a vendor compiler for performance

>  Clang is good enough to bootstrap itself on practically
> any platform I can think of or it can be cross-bootstrapped
> if needed.

Being able to bootstrap Clang on a platform is different from Clang being
100% compatible with a platform.  Clang can be built on Windows, but it's
far from usable as a system compiler on that platform.  Last time I
checked, Clang could not parse all of the SDK headers.  And forcing MinGW
isn't a solution either, not to mention the quagmire of incompatible
versions/distributions.  Please correct me if I am wrong, but I do not
believe you can build Clang with MSVC and then build Clang itself using the
Microsoft headers/libraries.  The C++ ABI support for MSVC in Clang is
still not 100% functional, I believe.

>  I think usage of any language features should be decided
> based on support from a either clang(n-j) release or a
> reference version (3.2 being my personal favorite)
> rather then on a common unbroken subset from a motley
> collection of other compilers.

While I would love to see this happen, I just don't think it's
practical/feasible currently.

> Just my 0.02$ after 2 months of building clang+llvm.
> PaweĊ‚
> > On Jan 9, 2013, at 2:38 AM, David Chisnall <David.Chisnall at
> cl.cam.ac.uk> wrote:
> >
> >> On 9 Jan 2013, at 04:49, Marc J. Driftmeyer wrote:
> >>
> >>> It's not a coincidence that GCC 4.2.1 is the baseline on FreeBSD
> considering the licensing of GPL restrictions on new releases.
> >>
> >> [With my FreeBSD hat on]
> >>
> >> Our plan for 10.0 is to ship clang only, with gcc 4.2.1 relegated to a
> compat package for tier 1 architectures.  This should be x86, x86-64, and
> ARMv6/7 (and maybe v8 if we're very lucky, but probably not).  MIPS and
> PowerPC are slowly migrating to clang, but will probably take a little bit
> longer (although given the progress that these are making, possibly not).
>  As these are tier 2 architectures, I don't have a problem requiring an
> external compiler or a cross compiler for the initial bootstrap build.
> >
> > Ok, that's good news!
> Kudos to FreeBSD!
> >
> >>
> >> However, our release cycle is (in theory) 6 months, but is out of phase
> with LLVM's and so at any given point we are likely to be one or two
> releases behind.
> >>
> >> As such, it's important to us to be able to build trunk clang with
> clang from at least two releases ago, and ideally four.  Losing this
> ability makes it very difficult for us to do the bootstrap toolchain build
> Since Thursday, February 4, 2010 we can always do
> clang(n-j) ... clang(n-1)clang(n) -> clang(n+1)
> >
> >
> > Can you make this more concrete for me?  If we made this change in LLVM
> 3.3, what version of Clang would you need us to be compatible with?  Would
> it be ok to require Clang 3.1 or later, or do you need clang 3.0 support?
> >
> > -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130110/46b8b776/attachment.html>

More information about the llvm-dev mailing list