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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
David Fang
http://www.csl.cornell.edu/~fang/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
