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 Mon, Oct 28, 2013 at 02:31:10PM -0700, Chris Lattner
wrote:
> 
> On Oct 28, 2013, at 2:19 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
> > 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.
> 
> Yes, good point.  A more logical one would be to go for 3.5/3.6 for
"VC2010" and "VC2012" feature adoption.
FWIW, I thought the agreement when this came up previously was that 3.4
could include C++11 features.  Delaying one more might help FreeBSD a
bit, but we've been planning as though 3.4 would break the ability to
build on gcc 4.2.
> > 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.
> 
> Ok.  If no-one has an objection, then putting it in the release notes (and
the announcement email!) makes sense.  We can make the switch a few weeks after
the release if no one has strongly objected.
Requiring GCC 4.7 or Clang 3.1 would work fine for us.  We may need to
jump through some hoops to keep ports working on FreeBSD 8.4 until the
end of support (June 30, 2015), but we're probably going to need to do
work there anyway with other code bases adopting C++11.

For FreeBSD 11 we plan to support compilation with Clang and an
externally bootstrapped GCC with support for GCC 4.9 and maybe 4.8 and
4.7 if someone does the work.  For us, the biggest thing that helps is
requirements stability.  Today you could probably pick a somewhat newer
Clang than 3.1 without much real impact on us, but it would hurt to have
the requirements change with every release.  From our perspective it's
much better to change no more than every two years or so.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/ee819230/attachment.sig>

Focusing on one comment:

On Mon, Oct 28, 2013 at 3:12 PM, Brooks Davis <brooks at freebsd.org>
wrote:
> Today you could probably pick a somewhat newer
> Clang than 3.1 without much real impact on us, but it would hurt to have
> the requirements change with every release.  From our perspective it's
> much better to change no more than every two years or so.
>
I think that from the project's perspective, we will have much better
success if we at least evaluate this after each release. That's the time
cycle on which we will have a reason to think about it.

I don't think that it makes sense to only change every two years. If you
want more stability, I think the easy path to that is to jump Clang
versions, say, every year. Then you'll control and slow down the upgrade
frequency on your end, but there will always be enough overlap with the
latest release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/a1e3423b/attachment.html>

For those driving c++11 in clang/llvm - Would it generally be acceptable 
to have a "sunrise" period where the preliminary evaluation has been 
done (buildbots, compiler evaluate.. etc) and the 1st actual c++11 
commit hits the repo. (30-60 days?)
-------------
My concern/thoughts - When we swap out STDCXX for libc++ - We aren't 
able to self host clang. This could be entirely *our* fault, but it 
hasn't been investigated extensively. (We also see Perennial C++ 
testsuite regressions which appear to come from libc++, but also not 
investiaged/confirmed) Having a sunrise period would allow us to 
investigate this as well as report any potentially blocking problems.

Having a gnu-free self hosting[1] policy attached to this would also be 
great - that makes a potentially easier backup solution to anyone on 
[linux] with older gnu compilers

[1] My simple explanation of self hosting
Stage 1 - g++ builds clang - bootstrapped clang builds it's own runtime 
libs -> clang-stage1
Stage 2 - clang-stage1 builds -> clang-stage2
Stage 3 - clang-stage2 builds -> clang-stage3

Typically in such a large c++ codebase like clang - any bad code 
generation issues would make stage3 fail. (Not guaranteed, but it's a 
pretty good sanity check and way to "dogfood" your own compiler)