[PATCH] Enable C++11
fang at csl.cornell.edu
Mon Jan 6 13:36:56 PST 2014
> 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
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]
>> 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 :-)
>> 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 :-)
>> the browser experts
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
More information about the cfe-commits