[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
reasons.
>
> 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
>
--
Thanks,
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