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

"C. Bergström" cbergstrom at pathscale.com
Mon Oct 28 17:06:22 PDT 2013


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)




More information about the llvm-dev mailing list