[PATCH] Enable C++11

[David Fang]

> The proposed patch can just be taken as a reminder that we're post-3.4 and 
> thinking about this seriously now. I think some developers are still using 
> old compilers day to day.

I'm not opposed to moving towards C++11-izing, and there's been some 
fair warning.  I've been maintaining a gcc-4.0-friendly [powerpc-darwin8] 
branch in the hopes of creating a bootstrappable clang with 'acceptable' 
quality codegen, enough to self-host with current libc++.  [see my post to 
llvmdev a few days ago on the status of this -- a lot has improved 
recently.]

I ask that introducing actual C++11 code into the source tree be held off 
"a little longer" so that I might have a window of stability where I can 
build a working C++11 clang/libc++ starting with (system) gcc-4.0.  Once 
that is achieved, this unofficial release (3.something-between-4-and-5) 
can be used to start future bootstraps of llvm/clang that require C++11.

It would be really nice to not require a bootstrap of gcc-4.8 for stage-1 
clang, but FSF gcc-4.8 give me unresolved issues on powerpc-darwin8.  I'd 
rather focus my limited time on in-tree issues in llvm/clang.  It's 
already a small chore maintaining this long-lived branch.

Anyways, that's my $0.025.  Please consider this wish before landing that 
first C++11-ized patch?

[begging kitty face]

David
#llvm-powerpc-darwin (oftc.net)

>>  but if you want to do it, the minimum I think we should do first:
>>
>>  - Document what versions of which compilers we're trying to support as
>>  host compilers.
>>  - Add at least some checks to try to error early and clearly at configure
>>  / cmake time on host compilers we don't really support (with a flag to
>>  bypass this)
>
> I focused on the CMake side, which does perform a check if the -std=c++11 
> flag is accepted, then tries fallback to -std=c++0x, and failing both emits 
> an error. Do you think we'll need more than that in practice? It might be 
> enough to use that and rely on Compiler.h for some period of time.

>>  - Document the C++11 features which we think are supported by these
>>  compilers (mostly MSVC restrictions I suspect)
>>  - Throw the switch in a way that folks can locally disable it for a while
>
> That's a good idea.
>
>>  - Then make it permanent and expose C++1y
>
> Yes :-)
>
> Alp.
>
>>
>>  Does that make sense?
>> 
>>
>>  On Mon, Jan 6, 2014 at 12:34 PM, Alp Toker <alp at nuanti.com
>>  <mailto:alp at nuanti.com>> wrote:
>>
>>      The attached patch enables C++11 by default in the CMake and
>>      Makefile build systems.
>>
>>      The old LLVM_ENABLE_CXX11 flag is retrofitted as LLVM_ENABLE_CXX1Y
>>      for those looking to try the latest experimental standard.
>>
>>      The CMake changes include an additional fallback to -std=c++0x.
>>      This fallback can hopefully be removed shortly when the remaining
>>      legacy build servers are upgraded.
>>
>>      No changes made to the MSVC configuration in this patch. I'm
>>      guessing Takumi will want to take care of that personally :-)
>>
>>      Alp.
>>
>>      --
>>      http://www.nuanti.com
>>      the browser experts
>> 
>>
>>      _______________________________________________
>>      cfe-commits mailing list
>>      cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>>      http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
>> 
>
>

-- 
David Fang
http://www.csl.cornell.edu/~fang/