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

Chris Lattner clattner at apple.com
Sun Oct 27 14:09:01 PDT 2013


On Oct 27, 2013, at 12:07 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Chris Lattner <clattner at apple.com> 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



More information about the llvm-dev mailing list