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

[Rui Ueyama]

On Thu, Oct 31, 2013 at 11:59 AM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Thu, Oct 31, 2013 at 10:06 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> Chrome still ships with VS2010.  LLVM is only brought into Chrome via
>> PNaCl, I think, but I don't think it's built with MSVC.  Maybe JF could say
>> more.
>>
>> The initial release of 2012 had lots of miscompiles, most of which
>> should've been fixed in update 1.  I think the story was the same for 2013.
>>
>> I'm not sure why Chrome hasn't moved up to 2012 now that bugs are fixed.
>>  My best guess would be that LTO memory usage increased, breaking the
>> 32-bit official release build.
>>
>> It sounds like WebKit will link in LLVM soon, and they may still be on
>> the same toolchain trajectory as Chrome.
>>
>> As Doug mentioned, a lot of LLVM users live close to TOT, so moving to
>> C++11 in two months is a much more immediate change for them than a release
>> 8 months away.
>>
>> Personally, I'd be happy to move, but it's not much trouble for me.  :)
>>  The only thing I don't like about C++11 so far from reading lld is to see
>> std::move slapped on every return value under the sun.  =P
>>
>
> Hmm. There's 23 matches for 'return std::move' in lld. Of those, 12 uses
> of std::move are redundant (and in fact harmful, since they're suppressing
> NRVO). 8 others will become redundant in C++14. The other 3 are performing
> some non-trivial ownership transfer.
>

I will remove those 12 redundant std::move()s. And yes, seems NRVO warning
would have value. :)


> I've been intending to add a warning to Clang for calls to std::move that
> suppress NRVO. Seems like it'd have value here. And then you'd have to read
> 'return std::move(...);' less =)
>
>
>> On Thu, Oct 31, 2013 at 9:41 AM, Douglas Gregor <dgregor at apple.com>wrote:
>>
>>>
>>> On Oct 31, 2013, at 9:18 AM, Renato Golin <renato.golin at linaro.org>
>>> wrote:
>>>
>>> On 31 October 2013 00:24, Eric Christopher <echristo at gmail.com> wrote:
>>>
>>>> The timeframe “2 whole years” might seem like a long time to us, but
>>>> not everybody lives in the world where they adopt new toolsets so quickly.
>>>>  That’s my concern about dropping VS 2010 support.  So this is both a
>>>> question about how fast Visual Studio moves, but also the people who use
>>>> Visual Studio.
>>>>
>>>> Agreed. I think the question here is whether or not it's reasonable for
>>>> this change and less whether or not it's reasonable as a path for each
>>>> release to then deprecate everything more than 2 years old. I'd like to get
>>>> rid of VS2010 because I want the features of 2012 and few of the current
>>>> people developing on windows have spoken up (and most of them positively),
>>>> but you do quite a bit of work and maintenance with windows so your
>>>> thoughts are definitely important here. Do you think it's reasonable?
>>>>
>>>
>>> You guys are still taking it too literally... ;)
>>>
>>> Let's take one decision at a time. We seem not to have any reason to
>>> keep VS2010 support. Check box.
>>>
>>>
>>> Not quite :). At present, we (= Apple) still have some dependencies on
>>> building top-of-tree Clang with VS2010. We’re currently investigating how
>>> quickly we can move those to VS2012 or newer.
>>>
>>> - Doug
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131031/4d4ad5f9/attachment.html>