[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