Using C++'11 language features in LLVM itself

Project Infrastructure LLVM Dev List Archives
#1

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?

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

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.

Just my 0.02$ after 2 months of building clang+llvm.

Paweł

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)

#2

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.

#3

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!

#4

>
>> 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.

#5

Pawel Wodnicki <root@32bitmicro.com> writes:

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

You're completely ignoring communities that compile code outside
llvm+clang. Any compiler chosen by that group has to be able to
correctly compile hundres if not thousands of source code files. It is
not easy to find such a compiler and that makes it an arduous process to
upgrade. Of course upgrades are done, but they're done conservatively.

                            -David

#6

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.

#7

As you have pointed out the reality is that for a long time
there will be a lot of different C++ code to maintain and for
practical reasons it makes no sens to throw away time tested tools
just to use some modern C++ style. At the same time I am not
convinced that it is worth the effort to introduce some C++11
features into LLVM and try to stay compatible with all these other
compilers.

So if the goal is to be able to use *any* however broken C++ compiler
to build LLVM and stay compatible with the platform compiler
then perhaps we should approach it differently. Ideally source
translation in clang could be used to "lower" C++11 code to
either C++03 or even C++98, worst case just use CPP backend.

I realize that Cfront approach does not have a good
track record but this could be a C++front translating
C++11 to older version of the C++ language.

Paweł

#8

Pawel Wodnicki <root@32bitmicro.com> writes:

So if the goal is to be able to use *any* however broken C++ compiler
to build LLVM and stay compatible with the platform compiler

No one ever said that. We're simply trying to determine which
reasonable set of compilers to support.

                                -David

#9

It's not speculation, it's asking for references to information. If there
was interpretation, then I would agree. But there is not.

#10

> Pawel Wodnicki <root@32bitmicro.com> writes:
>
>> Clang is good enough to bootstrap itself on practically
>> any platform I can think of or it can be cross-bootstrapped
>> if needed.
>
> You're completely ignoring communities that compile code outside
> llvm+clang. Any compiler chosen by that group has to be able to
> correctly compile hundres if not thousands of source code files. It is
> not easy to find such a compiler and that makes it an arduous process to
> upgrade. Of course upgrades are done, but they're done conservatively.
>
> -David
>
>

As you have pointed out the reality is that for a long time
there will be a lot of different C++ code to maintain and for
practical reasons it makes no sens to throw away time tested tools
just to use some modern C++ style. At the same time I am not
convinced that it is worth the effort to introduce some C++11
features into LLVM and try to stay compatible with all these other
compilers.

It's not a matter of *all* compilers. Once we establish a baseline, it
only matters for those compilers.

So if the goal is to be able to use *any* however broken C++ compiler
to build LLVM and stay compatible with the platform compiler
then perhaps we should approach it differently. Ideally source
translation in clang could be used to "lower" C++11 code to
either C++03 or even C++98, worst case just use CPP backend.

I realize that Cfront approach does not have a good
track record but this could be a C++front translating
C++11 to older version of the C++ language.

I wouldn't expect this to be a part of LLVM itself; if someone needs to
support an old/broken compiler, they can make this work themselves.

#11

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.

I am not speculating about legality of clang/LLVM.

But I will point out that raison d'etre for MingW existence
seems to be the ability to freely distribute their
Win32 headers and libraries.

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

Using anything blunt usually is not very effective.
I would advise some finesse, won't hurt your productivity
and might even be helpful.

Paweł

#12

So far it appears that the baseline is very limited, compared to the set of compilers actively in use.

-Krzysztof

#13

You don't have to select one compiler. We've got many production compilers installed (Intel, PGI, Cray, numerous versions of GCC), a number of official `friendly' versions maintained, and dozens of unofficial builds (e.g. clang).

Given the fast flux of the LLVM interfaces, getting hung-up on the lowest common denominator for a C++ compiler seems weird to me.

Marcus

#14

The only place it could possibly lead is a discussion of legal issues
around llvm/clang, which are not on-topic for this list.
If ya'll want to have a private discussion about it, go ahead.
But don't do it here.

#15

No, I was asking for a reference, not legal advice. If it turns into a
legal debate, *then* it's off topic. If I have to start a private
conversation for every piece of information I want, what is the point of
community conversations like these?

#16

It's not a matter of *all* compilers. Once we establish a baseline, it
only matters for those compilers.

So far it appears that the baseline is very limited, compared to the set
of compilers actively in use.

Unfortunately, that does appear to be the case. I think MSVC 2010 is a
reasonable requirement, but it seems like 2012 is the real target for C++11
features.

#17

It is, indeed, off topic. Danny is completely correct here.

The fact is that legal speculation, information, references, or anything
else *will* lead to a discussion, which shouldn't take place here. If you
want such information and to understand it, you should discuss it with a
lawyer.

This mailing list is for technical discussion. Let's keep it that way.

If you want to continue debating the semantics of this or whether or not to
discuss it on this list (something that seems a truly pointless meta
discussion), I'm asking you to take even that debate off the list so that
we can remain focused on the original question: C++11 features in LLVM and
Clang.

#18

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?

Here is a thread on using MS headers in FOSS for reference
when writing your own headers.

http://blog.2of1.org/2010/09/20/use-of-microsoft-windows-sdk-headers-as-foss-reference-ok/

#19

Alright, fair enough. I apologize for bringing it up. I thought asking Pawel for this references was within the merits of technical (not legal) discussion. Now I know. Thanks for clarifying!

#20

It is, indeed, off topic. Danny is completely correct here.

I have to ask. Have you had legal advice to stop the plebs talking
about such matters here? It always seems to get stomped on with great
gusto.

Tim.