<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 10, 2013 at 1:11 AM, Pawel Wodnicki <span dir="ltr"><<a href="mailto:root@32bitmicro.com" target="_blank">root@32bitmicro.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I have been following this discussion for a while and I think the<br>
question we should be asking is:<br>
<br>
Why do we want to even bother with all these other broken C++<br>
compilers in a first place?<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Clang is good enough to bootstrap itself on practically<br>
any platform I can think of or it can be cross-bootstrapped<br>
if needed.<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think usage of any language features should be decided<br>
based on support from a either clang(n-j) release or a<br>
reference version (3.2 being my personal favorite)<br>
rather then on a common unbroken subset from a motley<br>
collection of other compilers.<br></blockquote><div><br></div><div style>While I would love to see this happen, I just don't think it's practical/feasible currently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just my 0.02$ after 2 months of building clang+llvm.<br>
<br>
Paweł<br>
<br>
<br>
> On Jan 9, 2013, at 2:38 AM, David Chisnall <David.Chisnall at <a href="http://cl.cam.ac.uk" target="_blank">cl.cam.ac.uk</a>> wrote:<br>
><br>
>> On 9 Jan 2013, at 04:49, Marc J. Driftmeyer wrote:<br>
>><br>
>>> It's not a coincidence that GCC 4.2.1 is the baseline on FreeBSD considering the licensing of GPL restrictions on new releases.<br>
>><br>
>> [With my FreeBSD hat on]<br>
>><br>
>> 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.<br>
><br>
> Ok, that's good news!<br>
<br>
Kudos to FreeBSD!<br>
<br>
><br>
>><br>
>> 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.<br>
>><br>
>> 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<br>
<br>
Since Thursday, February 4, 2010 we can always do<br>
clang(n-j) ... clang(n-1)clang(n) -> clang(n+1)<br>
<br>
><br>
><br>
> 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?<br>
><br>
> -Chris<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div></div>