[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
Chandler Carruth
chandlerc at google.com
Mon Oct 28 14:19:19 PDT 2013
One thing I want to call out:
On Mon, Oct 28, 2013 at 8:20 AM, Chris Lattner <clattner at apple.com> wrote:
> I suppose what I'm saying is that we are currently not using *any* C++'11
> features. It seems like conservatively great progress for LLVM 3.4 to bump
> the minimum GCC requirement up to enable use of VC 2010-era features (like
> rvalue refs and simple stdlib features),
I am strongly opposed to this. Currently, we have people that are relying
on our C++98 status. This isn't actually about VC2010 issues, this is about
GCC support. I think it would be a disservice to change that in 3.4, only a
small number of weeks away from the branch point. That seems like very
little notice.
> then jump to VC2012 features in LLVM 3.5 assuming that goes well. We're
> talking about a 6 month delta between the two, and I think we'll learn a
> lot in the first step.
I think the biggest jump will be to have a floor at all, and I think we
should just pick on that makes sense, and advertise the day lights out of
it. Put it in the 3.4 release notes that going forward we're going to be
dropping support for older toolchains, etc., etc. This will really help
manage the expectations of users, and ensure that folks plan adequately for
3.5 and get C++11-supporting toolchains installed on their systems, etc.
I have also heard no serious objection to the three versions I gave as a
baseline: VC2012, GCC 4.7 (the series, not any specific patch release), and
Clang 3.1.
This also helps stage out the inevitable "lets rewrite the codebase" churn
> over more time.
I think this is a lost cause, and ultimately a (relatively) unimportant
one. We have great tools to cope with this as well. ;]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/60f558d6/attachment.html>
More information about the llvm-dev
mailing list