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

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)

On Mon, Oct 28, 2013 at 4:47 PM, "C. Bergström" <cbergstrom at
pathscale.com>wrote:
> 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?)
>
I really don't think we need this level of complexity to the planning. I
think we can give a heads up at a high level (as already discussed), check
the build bots are updated, and flip the switch.

> -------------
> My concern/thoughts - When we swap out STDCXX for libc++ - We aren't
able
> to self host clang.
>
No part of this relies on using libc++ on Linux instead of libstdc++.
That's an orthogonal issue which I'm not even attempting to address.

Certainly, the platforms with only libc++ are self hosting clang
successfully today.

> 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
>
Absolutely not. I really don't want to tie this to more things. If you
think we should pursue such a goal, fine, but it is independent of the
decision about using C++11, and not something I'm currently striving for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/e437d2c7/attachment.html>

On Mon, Oct 28, 2013 at 4:47 PM, "C. Bergström" <cbergstrom at
pathscale.com>wrote:
> 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?)
>
I believe we already have buildbots testing with C++11 enabled for many of
the configurations we support. (And we already use some of the new features
if C++11 support is available.) Plus a couple of LLVM subprojects are
already using C++11, and I believe they have buildbots.

In short, I don't think this is something for which we need any action
other than to check that we are already doing the right thing. We already
have a strongly-enforced policy of rolling back/fixing changes that break
bots, so if we are happy with our buildbot coverage, we're all good here.

> -------------
> 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.
>
[As an aside: I use libc++ for my Clang development (on Ubuntu Linux), and
it works for me (tm). This is with libstdc++ providing the ABI pieces,
rather than libc++abi or libcxxrt, though.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/e616bba4/attachment.html>

On Mon, Oct 28, 2013 at 8:01 PM, Richard Smith <richard at metafoo.co.uk>
wrote:
> On Mon, Oct 28, 2013 at 4:47 PM, "C. Bergström" <cbergstrom at
pathscale.com>
> wrote:
>>
>> 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?)
>
>
> I believe we already have buildbots testing with C++11 enabled for many of
> the configurations we support. (And we already use some of the new features
> if C++11 support is available.) Plus a couple of LLVM subprojects are
> already using C++11, and I believe they have buildbots.
>
> In short, I don't think this is something for which we need any action
other
> than to check that we are already doing the right thing. We already have a
> strongly-enforced policy of rolling back/fixing changes that break bots, so
> if we are happy with our buildbot coverage, we're all good here.
I think we still have some build bot needs on the Visual Studio front.
 Most notably, a VS 2013 build bot now that the release has been
RTMed.

(Orthogonal to the C++11 discussion, we also could very much use at
least one VS Debug build builder to catch all of the problems that can
only be caught via debug builds, like checked iterators and whatnot.)

~Aaron

On 10/29/13 06:52 AM, Chandler Carruth wrote:
>
> On Mon, Oct 28, 2013 at 4:47 PM, "C. Bergström" 
> <cbergstrom at pathscale.com <mailto:cbergstrom at
pathscale.com>> wrote:
>
>     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?)
>
>
> I really don't think we need this level of complexity to the planning. 
> I think we can give a heads up at a high level (as already discussed), 
> check the build bots are updated, and flip the switch.
fuzzy://How much "heads up"
>
>     -------------
>     My concern/thoughts - When we swap out STDCXX for libc++ - We
>     aren't able to self host clang.
>
>
> No part of this relies on using libc++ on Linux instead of libstdc++. 
> That's an orthogonal issue which I'm not even attempting to
address.
>
> Certainly, the platforms with only libc++ are self hosting clang 
> successfully today.
Hmm....
>
>     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
>
>
> Absolutely not. I really don't want to tie this to more things. If you 
> think we should pursue such a goal, fine, but it is independent of the 
> decision about using C++11, and not something I'm currently striving
for.
-1
If we do it - we should do it properly.
---------
I'm strongly against anything which forces this to rely on gnu runtime 
and libs.
---------
Further - While c++11 is the best thing ever - Is there actually a 
driving use case where using c++11 features will significantly improve 
the quality of the codebase? implementation perspective or performance? 
Are there coding style guidelines which should be updated - I've seen 
code (ab)using auto where it was mostly author preference and not really 
necessary. You really push for this, but the underlying motivation still 
seems unclear. (Show me the c++11 code in the subproject which is the 
root cause please)

On 10/29/13 07:01 AM, Richard Smith wrote:
>
> [As an aside: I use libc++ for my Clang development (on Ubuntu Linux), 
> and it works for me (tm). This is with libstdc++ providing the ABI 
> pieces, rather than libc++abi or libcxxrt, though.]
libc++ "works" for us as well, but it can't self host. I don't
know if
your "works" and my definition of works is 1:1. Can your clang+libc++ 
build itself multiple levels deep?

I believe both ABI alternatives are drop-in replacements and I hope not 
the root cause of what we observed. (We are only testing with libcxxrt 
though)
--------------
I could totally be wrong about libc++ and it's "our" fault in the 
testing we've done. I apologize if this is a non-issue and I hope during 
the "heads up" phase we have time to actually interject if there are 
potentially fatal issues. Forcing a dependency on gnu runtime/libs/STL 
is a serious regression imho.