llvm dev - Jan 2013 - [LLVMdev] Using C++'11 language features in LLVM itself

On 1/10/2013 7:32 AM, Justin Holewinski wrote:
> 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.
> 
In LLVM+platform_C++_compiler scenario the safest way would be to use
no C++11 features in LLVM at all and just keep the status quo.
> 
>>
>>  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 do not think you can legally make clang a system compiler on
Windows without licensing headers/libraries from Microsoft.
So inability to parse all of the SDK headers is a non issue to me,
can't use them anyway.

 Seems the only sensible open source way to use clang on Windows
platform is to use either MinGW or Cygwin environment which works fine!
Clang can bootstrap itself on either of them using clang(n-1).

"quagmire of incompatible versions/distributions" - describes very
well the situation I would rather avoid by using clang.
> 
>>
>>  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.
> 
> 
At some point it is no longer a technical question as
all the effort spent on ensuring compatibility with
the other compilers could be redirected towards making
clang better!
>>
>> 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
>>
> 
> 
>

On Thu, Jan 10, 2013 at 10:08 AM, Pawel Wodnicki <root at
32bitmicro.com>wrote:
> On 1/10/2013 7:32 AM, Justin Holewinski wrote:
> > 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.
> >
>
> In LLVM+platform_C++_compiler scenario the safest way would be to use
> no C++11 features in LLVM at all and just keep the status quo.
>
That's exactly the point of this discussion.  What C++11 features could be
feasibly allow without alienating too many users with diverse requirements.

>
> >
> >>
> >>  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 do not think you can legally make clang a system compiler on
> Windows without licensing headers/libraries from Microsoft.
> So inability to parse all of the SDK headers is a non issue to me,
> can't use them anyway.
>
Care to cite a source?

>
>  Seems the only sensible open source way to use clang on Windows
> platform is to use either MinGW or Cygwin environment which works fine!
> Clang can bootstrap itself on either of them using clang(n-1).
>
That's essentially my point!  If you require Clang to build LLVM, and Clang
requires you to use MinGW/Cygwin, then LLVM on Windows will also require
MinGW/Cygwin.  This is not acceptable for some use-cases.  Integrating with
MSVC-compiled code is one such example.

>
> "quagmire of incompatible versions/distributions" - describes
very
> well the situation I would rather avoid by using clang.
>
And that's exactly the situation you get on Windows if you use Clang right
now.  Which MinGW distribution do you use?  The "official" one?  One
of the
numerous ports through-out the internet, each with their own extra features
and compatibility issues with each other?  What if you want to integrate
with some code compiled with MSVC?

I think at the very least we need to support the "official" system
compiler
for every supported platform.  For Linux, that's GCC (baseline version
TBD).  For Mac, that's Apple's Clang.  For Windows, that's MSVC.  As
much
as I would love to just use clang/gcc on Windows, it's just not feasible
currently.

>
> >
> >>
> >>  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.
> >
> >
>
> At some point it is no longer a technical question as
> all the effort spent on ensuring compatibility with
> the other compilers could be redirected towards making
> clang better!
>
Agreed!  I just don't think we've hit that point yet.

>
> >>
> >> 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/26eb55c8/attachment.html>

>>
>>  I do not think you can legally make clang a system compiler on
>> Windows without licensing headers/libraries from Microsoft.
>> So inability to parse all of the SDK headers is a non issue to me,
>> can't use them anyway.
>
>
> Care to cite a source?
Please don't (either of you) randomly speculate on the legality of
clang/LLVM.

To be perfectly blunt (without trying to actually be offensive):
You aren't qualified, and it's not helpful or productive.