Re: RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
133 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chandler Carruth-2
(re-sending to the actual mailing lists... go go gadget typos!)


On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <[hidden email]> wrote:
Greetings,

This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.

I am seriously concerned that if we don't do this now, we will miss out on the accelerating trend of C++ as a language.

Concrete long term proposal:

We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.

Some observations:
- I specifically am wording this to enable the mainline to use features sooner. People who are unable to use an *even more* modern toolchain will necessarily stay with each release.
- This is an aggressive timeline. That is intentional. There is increasing pressure for LLVM to make use of new C++ language and library features.
- There is always the option of checking out an old release, building it, and then using that compiler to build the latest release or to build the mainline compiler.
- The goal is to only change the supported toolchain set and thus C++ dialect after a release branches to avoid confusion, churn, and impeding QA on a release. People can check out trunk and get an idea of whether they will have problems with the next release.
- I have historically been more conservative on this topic, but listening to many people and looking at some of the C++ features we are missing, I think the right strategy for the project is a more aggressive one.


One short term caveat: Windows is special.

I don't think we should follow the 2-year rule for Windows. It really is special for at least three reasons:
1) We can't bootstrap on Windows. While there is tons of exciting work going on here to change that, even then the quality of Windows support is likely to change very rapidly.
2) Visual Studio's C++ support moved very slowly for a long time, and is now improving at an amazing rate. We shouldn't be hampered by past problems and should take advantage of this recent progress.
3) We have less insight into when new versions of the MSVC++ toolchain will arrive.

So my suggestion is that, at least during the rapid evolution of VS's C++11 support and Clang's Windows support, we support building with the most recent 2 versions of VS available at the *prior* release. For example when we branch for 3.4, the two versions will be 2012 and 2013. Those two would be supported on mainline from then through 3.5, and when we branch for 3.5 we would re-evaluate.

NOTE: This would drop support for VS 2010!!! That is a huge change, hence my suggesting it only *after* we branch for 3.4. It gives us an entire release cycle of notice for people relying on it.


Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:

GCC 4.7
Clang 3.1
VS 2012

Some notable features we would get to use:

- r-value references, move semantics, etc
- auto
- range for loops
- lambdas
- static_assert
- nullptr
- std::unique_ptr, std::tuple, some other nice library stuff


These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.

-Chandler


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Rafael Espíndola
>> GCC 4.7
>> Clang 3.1
>> VS 2012

Xcode 4.2's clang?

Do we already have bots with all these versions?

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

David Chisnall-5
In reply to this post by Chandler Carruth-2
On 27 Oct 2013, at 09:31, Benjamin Kramer <[hidden email]> wrote:

> - Freebsd 10 is on Clang/libc++ by default, FreeBSD 9 also shipped Clang. Don't see problems here.

Note that this is only for x86 and ARM.  For PowerPC64 and MIPS, which look as if they'll be supported by LLVM/Clang soon (we now have PowerPC64 working, but the kernel must be compiled at -O0 or it doesn't boot, MIPS is still quite buggy, but getting there), we're still shipping gcc 4.2.1.  These are tier 2 platforms, so we could cross-compile the toolchain from x86 for bootstrapping, but it would be quite painful.

David


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chris Lattner-2
In reply to this post by Chandler Carruth-2
On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <[hidden email]> wrote:
> Greetings,
>
> This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.

Awesome, thank you for spearheading this discussion.  We really need to move to some C++'11 support, it is just a question of how and when.  We also had a discussion from a few months ago about this, can you summarize where we left off?  I thought there was a tentative plan for LLVM 3.4 (or maybe it was after 3.4 branched).


> I am seriously concerned that if we don't do this now, we will miss out on the accelerating trend of C++ as a language.

I'm not worried about the "accelerating trend", I just think we'll all be more productive.

> Concrete long term proposal:
>
> We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.

I don't think it makes sense to have a hard policy like this.  It is fine to have a goal that allows us to continue picking up new features over time, but I think each such change will have to be discussed (at length) with the specifics of which interesting host configurations we would be dropping.

> Some observations:
> - I specifically am wording this to enable the mainline to use features sooner. People who are unable to use an *even more* modern toolchain will necessarily stay with each release.
> - This is an aggressive timeline. That is intentional. There is increasing pressure for LLVM to make use of new C++ language and library features.
> - There is always the option of checking out an old release, building it, and then using that compiler to build the latest release or to build the mainline compiler.
> - The goal is to only change the supported toolchain set and thus C++ dialect after a release branches to avoid confusion, churn, and impeding QA on a release. People can check out trunk and get an idea of whether they will have problems with the next release.
> - I have historically been more conservative on this topic, but listening to many people and looking at some of the C++ features we are missing, I think the right strategy for the project is a more aggressive one.

I really want this to happen, but it needs to be done in the right way, balancing the cost to the community to obsolete old configurations.  As such, I agree with everything except your last point here :-)

> One short term caveat: Windows is special.

I don't see how it is special.  We should just look at all of the compilers we need to support, and factor that set in.  We should continue to increment the baseline compilers over time, but a global "two year old compilers only" policy doesn't make sense to me.  I also think that windows will be the lowest bar anyway.

> Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:
>
> GCC 4.7
> Clang 3.1
> VS 2012

This seems overly aggressive to me.  Why not start by baselining at VC++ 2010, and bump up everything else to match?  That would give us some basic C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that goes well.

-Chris

>
> Some notable features we would get to use:
>
> - r-value references, move semantics, etc
> - auto
> - range for loops
> - lambdas
> - static_assert
> - nullptr
> - std::unique_ptr, std::tuple, some other nice library stuff
>
>
> These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Joerg Sonnenberger
In reply to this post by Chandler Carruth-2
On Sun, Oct 27, 2013 at 02:24:58AM -0700, Chandler Carruth wrote:

> > Now for the carrot: if we go with this plan, then immediately after
> > branching for 3.4,  we would be able to use the vast majority of C++11
> > features, targeting the following as the oldest toolchains supported
> > through the 3.5 release timeframe:
> >
> > GCC 4.7
> > Clang 3.1
> > VS 2012
> >
> > Some notable features we would get to use:
> >
> > - r-value references, move semantics, etc
> > - auto
> > - range for loops
> > - lambdas
> > - static_assert
> > - nullptr
> > - std::unique_ptr, std::tuple, some other nice library stuff

It would be nice to keep the list to things that don't require too much
support from the STL implementation. Locale support and std::thread in
the various forms are a real show stopper for bootstrapping otherwise.

Joerg
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Evan Cheng-2
In reply to this post by Chris Lattner-2

On Oct 27, 2013, at 11:18 AM, Chris Lattner <[hidden email]> wrote:

> On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <[hidden email]> wrote:
>> Greetings,
>>
>> This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.
>
> Awesome, thank you for spearheading this discussion.  We really need to move to some C++'11 support, it is just a question of how and when.  We also had a discussion from a few months ago about this, can you summarize where we left off?  I thought there was a tentative plan for LLVM 3.4 (or maybe it was after 3.4 branched).

I have a quick question on this. Apology if this has already been answered in the past. Am I correct in assuming this also force changes to other projects which link in LLVM?

Evan

>
>
>> I am seriously concerned that if we don't do this now, we will miss out on the accelerating trend of C++ as a language.
>
> I'm not worried about the "accelerating trend", I just think we'll all be more productive.
>
>> Concrete long term proposal:
>>
>> We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.
>
> I don't think it makes sense to have a hard policy like this.  It is fine to have a goal that allows us to continue picking up new features over time, but I think each such change will have to be discussed (at length) with the specifics of which interesting host configurations we would be dropping.
>
>> Some observations:
>> - I specifically am wording this to enable the mainline to use features sooner. People who are unable to use an *even more* modern toolchain will necessarily stay with each release.
>> - This is an aggressive timeline. That is intentional. There is increasing pressure for LLVM to make use of new C++ language and library features.
>> - There is always the option of checking out an old release, building it, and then using that compiler to build the latest release or to build the mainline compiler.
>> - The goal is to only change the supported toolchain set and thus C++ dialect after a release branches to avoid confusion, churn, and impeding QA on a release. People can check out trunk and get an idea of whether they will have problems with the next release.
>> - I have historically been more conservative on this topic, but listening to many people and looking at some of the C++ features we are missing, I think the right strategy for the project is a more aggressive one.
>
> I really want this to happen, but it needs to be done in the right way, balancing the cost to the community to obsolete old configurations.  As such, I agree with everything except your last point here :-)
>
>> One short term caveat: Windows is special.
>
> I don't see how it is special.  We should just look at all of the compilers we need to support, and factor that set in.  We should continue to increment the baseline compilers over time, but a global "two year old compilers only" policy doesn't make sense to me.  I also think that windows will be the lowest bar anyway.
>
>> Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:
>>
>> GCC 4.7
>> Clang 3.1
>> VS 2012
>
> This seems overly aggressive to me.  Why not start by baselining at VC++ 2010, and bump up everything else to match?  That would give us some basic C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that goes well.
>
> -Chris
>
>>
>> Some notable features we would get to use:
>>
>> - r-value references, move semantics, etc
>> - auto
>> - range for loops
>> - lambdas
>> - static_assert
>> - nullptr
>> - std::unique_ptr, std::tuple, some other nice library stuff
>>
>>
>> These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Renato Golin-2
In reply to this post by David Chisnall-5
Hi folks,

I'm up for it. I agree there are issues to work around for specific distros, but this is dragging for far too long. The main reasons against it until last year was: "this is not the standard yet", and "compiler support is patchy". I think we're past that, now.


On 27 October 2013 13:57, David Chisnall <[hidden email]> wrote:
Note that this is only for x86 and ARM.  For PowerPC64 and MIPS, which look as if they'll be supported by LLVM/Clang soon (we now have PowerPC64 working, but the kernel must be compiled at -O0 or it doesn't boot, MIPS is still quite buggy, but getting there), we're still shipping gcc 4.2.1.  These are tier 2 platforms, so we could cross-compile the toolchain from x86 for bootstrapping, but it would be quite painful.

Well, GCC 4.6 is going into maintenance mode, and there's a lot of work going on 4.7+ for cross-compilation. If anything, driving this forward will mean GCC will get better on these platforms because people will start to report more problems with the newer versions. I think that shipping any Unix variant with GCC 4.2 is, in its own, a much bigger problem than anything we've been discussing so far, and needs to be tackled in separate.

It's what people are saying about Windows. If we stop any progress because one specific platform has one specific self-inflicted problem, we'll never move. As it has been said already, there's always the chance to get an older LLVM (up to 3.4) and use that to compiler the newer LLVM.

cheers,
--renato

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chris Lattner-2
In reply to this post by Evan Cheng-2

On Oct 27, 2013, at 11:46 AM, Evan Cheng <[hidden email]> wrote:

>
> On Oct 27, 2013, at 11:18 AM, Chris Lattner <[hidden email]> wrote:
>
>> On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <[hidden email]> wrote:
>>> Greetings,
>>>
>>> This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.
>>
>> Awesome, thank you for spearheading this discussion.  We really need to move to some C++'11 support, it is just a question of how and when.  We also had a discussion from a few months ago about this, can you summarize where we left off?  I thought there was a tentative plan for LLVM 3.4 (or maybe it was after 3.4 branched).
>
> I have a quick question on this. Apology if this has already been answered in the past. Am I correct in assuming this also force changes to other projects which link in LLVM?

Yes.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chris Lattner-2
In reply to this post by Evan Cheng-2

On Oct 27, 2013, at 11:46 AM, Evan Cheng <[hidden email]> wrote:

>
> On Oct 27, 2013, at 11:18 AM, Chris Lattner <[hidden email]> wrote:
>
>> On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <[hidden email]> wrote:
>>> Greetings,
>>>
>>> This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.
>>
>> Awesome, thank you for spearheading this discussion.  We really need to move to some C++'11 support, it is just a question of how and when.  We also had a discussion from a few months ago about this, can you summarize where we left off?  I thought there was a tentative plan for LLVM 3.4 (or maybe it was after 3.4 branched).
>
> I have a quick question on this. Apology if this has already been answered in the past. Am I correct in assuming this also force changes to other projects which link in LLVM?

This will affect anyone using the LLVM C++ API.  It shouldn't affect clients of the C APIs.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chris Lattner-2
In reply to this post by Chris Lattner-2
On Oct 27, 2013, at 12:07 PM, Óscar Fuentes <[hidden email]> wrote:

> Chris Lattner <[hidden email]> writes:
>
>>> One short term caveat: Windows is special.
>
> s/Windows/Visual Studio.
>
> MinGW has the latest and greatest gcc.
>
>> I don't see how it is special.
>
> It is special, sadly, and I'm not talking about C++11 support only, but
> about the policies MS follows which too often makes very inconvenient
> (or even impossible) to upgrade to newer VS versions. The latest example
> that comes to mind was the release of VS2012: they removed Windows XP
> support, as if upgrading the OS is a non-issue if you ask for it to your
> users on a polite tone. An uproar followed and they backpedaled on a
> service pack some months later, but that not always happens.

I'm sorry, let me clarify.  I'm saying that MSVC shouldn't be special from an LLVM policy perspective.  We shouldn't have a general rule with an exception for MSVC: we should have a general rule that includes MSVC user's requirements as well.

This is why I don't like a general rule of "anything older than 2 years isn't supported".

>>> Now for the carrot: if we go with this plan, then immediately after
>>> branching for 3.4, we would be able to use the vast majority of
>>> C++11 features, targeting the following as the oldest toolchains
>>> supported through the 3.5 release timeframe:
>>>
>>> GCC 4.7
>>> Clang 3.1
>>> VS 2012
>>
>> This seems overly aggressive to me. Why not start by baselining at
>> VC++ 2010, and bump up everything else to match?
>
> IIRC the only significant difference among VS 2012 and VS 2010 is range
> for loops.

Which is really sad, given how nice they are, but I think it would be huge progress to move LLVM 3.4 to require the VS 2010 feature set (and the corresponding GCC/clang/etc versions).  We can move up to VS 2012 as a second step and second discussion.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Aaron Ballman-2
On Sun, Oct 27, 2013 at 5:09 PM, Chris Lattner <[hidden email]> wrote:

> On Oct 27, 2013, at 12:07 PM, Óscar Fuentes <[hidden email]> wrote:
>> Chris Lattner <[hidden email]> writes:
>>
>>>> One short term caveat: Windows is special.
>>
>> s/Windows/Visual Studio.
>>
>> MinGW has the latest and greatest gcc.
>>
>>> I don't see how it is special.
>>
>> It is special, sadly, and I'm not talking about C++11 support only, but
>> about the policies MS follows which too often makes very inconvenient
>> (or even impossible) to upgrade to newer VS versions. The latest example
>> that comes to mind was the release of VS2012: they removed Windows XP
>> support, as if upgrading the OS is a non-issue if you ask for it to your
>> users on a polite tone. An uproar followed and they backpedaled on a
>> service pack some months later, but that not always happens.
>
> I'm sorry, let me clarify.  I'm saying that MSVC shouldn't be special from an LLVM policy perspective.  We shouldn't have a general rule with an exception for MSVC: we should have a general rule that includes MSVC user's requirements as well.
>
> This is why I don't like a general rule of "anything older than 2 years isn't supported".
>
>>>> Now for the carrot: if we go with this plan, then immediately after
>>>> branching for 3.4, we would be able to use the vast majority of
>>>> C++11 features, targeting the following as the oldest toolchains
>>>> supported through the 3.5 release timeframe:
>>>>
>>>> GCC 4.7
>>>> Clang 3.1
>>>> VS 2012
>>>
>>> This seems overly aggressive to me. Why not start by baselining at
>>> VC++ 2010, and bump up everything else to match?
>>
>> IIRC the only significant difference among VS 2012 and VS 2010 is range
>> for loops.
>
> Which is really sad, given how nice they are, but I think it would be huge progress to move LLVM 3.4 to require the VS 2010 feature set (and the corresponding GCC/clang/etc versions).  We can move up to VS 2012 as a second step and second discussion.

I may be remembering incorrectly, but I thought we already supported
only VS2010 and higher today.  AFAIK, there are no 2008 build bots as
part of the process, and I've not seen a 2008-specific patch for
compatibility in ages.

~Aaron

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chris Lattner-2

On Oct 27, 2013, at 2:20 PM, Aaron Ballman <[hidden email]> wrote:

>>>>>
>>>>> Now for the carrot: if we go with this plan, then immediately after
>>>>> branching for 3.4, we would be able to use the vast majority of
>>>>> C++11 features, targeting the following as the oldest toolchains
>>>>> supported through the 3.5 release timeframe:
>>>>>
>>>>> GCC 4.7
>>>>> Clang 3.1
>>>>> VS 2012
>>>>
>>>> This seems overly aggressive to me. Why not start by baselining at
>>>> VC++ 2010, and bump up everything else to match?
>>>
>>> IIRC the only significant difference among VS 2012 and VS 2010 is range
>>> for loops.
>>
>> Which is really sad, given how nice they are, but I think it would be huge progress to move LLVM 3.4 to require the VS 2010 feature set (and the corresponding GCC/clang/etc versions).  We can move up to VS 2012 as a second step and second discussion.
>
> I may be remembering incorrectly, but I thought we already supported
> only VS2010 and higher today.  AFAIK, there are no 2008 build bots as
> part of the process, and I've not seen a 2008-specific patch for
> compatibility in ages.

Even better!  Can we start adopting C++'11 features in LLVM 3.3 then?

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Renato Golin-2
On 27 October 2013 15:25, Chris Lattner <[hidden email]> wrote:
Even better!  Can we start adopting C++'11 features in LLVM 3.3 then?

This could be one of the design guidelines: use any feature supported by the last LLVM release.

Which could force some distros to compile Clang more than once, but it could also mean people would migrate faster to more modern compilers.

cheers,
--renato

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chris Lattner-2

On Oct 27, 2013, at 3:39 PM, Renato Golin <[hidden email]> wrote:

On 27 October 2013 15:25, Chris Lattner <[hidden email]> wrote:
Even better!  Can we start adopting C++'11 features in LLVM 3.3 then?

This could be one of the design guidelines: use any feature supported by the last LLVM release.

Which could force some distros to compile Clang more than once, but it could also mean people would migrate faster to more modern compilers.

I'm not sure what you mean.  Are your proposing that clang 3.4 use any features supported by clang 3.3?  If so, that won't work, because clang can't self-host on all interesting architectures, e.g. it isn't fully ABI compatible with Visual C++ (yet).

-Chris


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Renato Golin-2
On 27 October 2013 15:53, Chris Lattner <[hidden email]> wrote:
I'm not sure what you mean.  Are your proposing that clang 3.4 use any features supported by clang 3.3?  If so, that won't work, because clang can't self-host on all interesting architectures, e.g. it isn't fully ABI compatible with Visual C++ (yet).

No, not yet. Certainly not for 3.4!

My comment was more to the effect that we could use this as a target for the future (and probably never achieve it), thus why "design guideline" and not a developer policy.

We'll have to make sure we can do it on all "interesting" architectures first (given all constraints).

--renato  

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chandler Carruth-2
In reply to this post by Chris Lattner-2
On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <[hidden email]> wrote:
On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <[hidden email]> wrote:> Concrete long term proposal:
>
> We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.

I don't think it makes sense to have a hard policy like this.  It is fine to have a goal that allows us to continue picking up new features over time, but I think each such change will have to be discussed (at length) with the specifics of which interesting host configurations we would be dropping.

I didn't really intend to indicate this would be a hard policy, more that it would be the guideline. Part of the idea is that after each release branch is cut we could evaluate what a reasonable baseline would look like.

I do think that 2 years is a good guideline, in part because two of the three toolchains which impact us most already use time-driven release cycles.

My hope is that we could *strive* for no more than two years of support for older toolchains as a way to push ourselves to not let this slip.


An obvious other input to this decision would be exactly what Benjamin brought up: we should look at what toolchain versions various OSes are shipping with. However, I think the diversity of OS is too broad to be easily explained in our getting started docs, etc. I would rather use the OS situation to inform the particular versions of each toolchain that we try to support, but to word the decision in terms of the toolchain versions.
 

> One short term caveat: Windows is special.

I don't see how it is special.  We should just look at all of the compilers we need to support, and factor that set in.  We should continue to increment the baseline compilers over time, but a global "two year old compilers only" policy doesn't make sense to me.  I also think that windows will be the lowest bar anyway.

See above. I'm not interested in a hard policy. I think MSVC will end up being special because we may realistically want a *narrower* set of toolchains supported there given both the rapid advances of MSVC in the last year, and the rapid changes to Clang and LLVM's role on that platform.

(And note, I misspoke previously, clearly MinGW is just GCC, I'm talking about MSVC here)

> Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:
>
> GCC 4.7
> Clang 3.1
> VS 2012

This seems overly aggressive to me.  Why not start by baselining at VC++ 2010, and bump up everything else to match?  That would give us some basic C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that goes well.

As others have pointed out, our baseline is already VS 2010, but our C++11 features have been held back by concern over GCC. I think the time frame is right to jump all the way to GCC 4.7 as the target for our 3.5 release, and would like to bump VS to 2012 at the same time if at all possible.

This isn't just a bump either, it brings things that I think will be very useful:
- Fixed semantics for r-value references that is relevant to using move semantics broadly in LLVM
- Range-based for loops, because as much as people say it "just reduces boiler plate", omg it is so much nicer
- better concurrency support, notably we may be able to use the standard atomics library (with some testing and restrictions) which have compiler assistance behind them.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chandler Carruth-2
In reply to this post by Joerg Sonnenberger

On Sun, Oct 27, 2013 at 11:30 AM, Joerg Sonnenberger <[hidden email]> wrote:
> > Some notable features we would get to use:
> >
> > - r-value references, move semantics, etc
> > - auto
> > - range for loops
> > - lambdas
> > - static_assert
> > - nullptr
> > - std::unique_ptr, std::tuple, some other nice library stuff

It would be nice to keep the list to things that don't require too much
support from the STL implementation. Locale support and std::thread in
the various forms are a real show stopper for bootstrapping otherwise.

Strong agreement. I think the most interesting would be the parts that need compiler assistance, such as type traits and atomics. Even then, the nice thing about the library is that we can easily test out the waters, and supplement with our own libraries as needed. We have a harder time of that with language features.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chandler Carruth-2
In reply to this post by Renato Golin-2

On Sun, Oct 27, 2013 at 4:07 PM, Renato Golin <[hidden email]> wrote:
On 27 October 2013 15:53, Chris Lattner <[hidden email]> wrote:
I'm not sure what you mean.  Are your proposing that clang 3.4 use any features supported by clang 3.3?  If so, that won't work, because clang can't self-host on all interesting architectures, e.g. it isn't fully ABI compatible with Visual C++ (yet).

No, not yet. Certainly not for 3.4!

My comment was more to the effect that we could use this as a target for the future (and probably never achieve it), thus why "design guideline" and not a developer policy.

We'll have to make sure we can do it on all "interesting" architectures first (given all constraints).

I think that just establishing a floor on the problem (a soft one, which naturally has to be interpreted based on the realities at the time) is the best first step. I *don't* want to lose the ability to host LLVM and Clang with reasonably modern C++ toolchains that are not Clang-derived. I *do* want to set expectations with clear guidelines for what we consider "reasonably modern" to be.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Dix Lorenz
In reply to this post by Chris Lattner-2

On 27.10.2013, at 20:07, Óscar Fuentes <[hidden email]> wrote:

> Chris Lattner <[hidden email]> writes:
>
>>> One short term caveat: Windows is special.
>
> s/Windows/Visual Studio.
>
> MinGW has the latest and greatest gcc.
>
>> I don't see how it is special.
>
> It is special, sadly, and I'm not talking about C++11 support only, but
> about the policies MS follows which too often makes very inconvenient
> (or even impossible) to upgrade to newer VS versions. The latest example
> that comes to mind was the release of VS2012: they removed Windows XP
> support, as if upgrading the OS is a non-issue if you ask for it to your
> users on a polite tone. An uproar followed and they backpedaled on a
> service pack some months later, but that not always happens.

I might be mistaken, but to compile for WinXP on VS 2012 you have to switch the Platform Toolset and AFAICT that means it will essentially be using the VS 2010 compiler and libraries. So when it comes to using newer C++ functionality you will still be stuck on the VS 2010 level even if you are using VS 2012 and if you are using any VS2012 improvements you will not be able to compile for XP.

Basically (again: AFAICT): if you want clang to be compiled for WinXP using VS, the C++ features of VS 2010 are a hard limit and that will not change.

Dix


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

C Bergström
On 10/28/13 11:45 AM, Dix Lorenz wrote:

> On 27.10.2013, at 20:07, Óscar Fuentes <[hidden email]> wrote:
>
>> Chris Lattner <[hidden email]> writes:
>>
>>>> One short term caveat: Windows is special.
>> s/Windows/Visual Studio.
>>
>> MinGW has the latest and greatest gcc.
>>
>>> I don't see how it is special.
>> It is special, sadly, and I'm not talking about C++11 support only, but
>> about the policies MS follows which too often makes very inconvenient
>> (or even impossible) to upgrade to newer VS versions. The latest example
>> that comes to mind was the release of VS2012: they removed Windows XP
>> support, as if upgrading the OS is a non-issue if you ask for it to your
>> users on a polite tone. An uproar followed and they backpedaled on a
>> service pack some months later, but that not always happens.
> I might be mistaken, but to compile for WinXP on VS 2012 you have to switch the Platform Toolset and AFAICT that means it will essentially be using the VS 2010 compiler and libraries. So when it comes to using newer C++ functionality you will still be stuck on the VS 2010 level even if you are using VS 2012 and if you are using any VS2012 improvements you will not be able to compile for XP.
>
> Basically (again: AFAICT): if you want clang to be compiled for WinXP using VS, the C++ features of VS 2010 are a hard limit and that will not change.
XP mainstream support is already EOL and extended support is  April 2014
http://windows.microsoft.com/en-us/windows/products/lifecycle

I can guess it may get extended, but imho it seems unreasonable to hold
up clang based on a non-supported product. (Yes the reality is many many
people will continue to use it, but....)

Wasn't VS 2012 express the 1st to ship a free 64bit C++ compiler?
--------
My vote would be 2012+ and drop 2010
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
1234 ... 7