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

On Sun, Oct 27, 2013 at 5:09 PM, Chris Lattner <clattner at apple.com>
wrote:
> 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.
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

On Oct 27, 2013, at 2:20 PM, Aaron Ballman <aaron at aaronballman.com>
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

On 27 October 2013 15:25, Chris Lattner <clattner at apple.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/09077d81/attachment.html>