llvm and clang actually can be compiled w/ C++11 support. attached patches will add a corresponding USE flag to both ebuilds. Reproducible: Always
Created attachment 352592 [details, diff] add c++0x to llvm 3.3 ebuild
Created attachment 352594 [details, diff] add c++0x to clang 3.3 ebuild
As far as I can see, the only thing the configure switch does is adding '-std=c++11' to the compiler command-line.
(In reply to Michał Górny from comment #3) > As far as I can see, the only thing the configure switch does is adding > '-std=c++11' to the compiler command-line. which is may affect both -- compile and run time performance. anyway effect of this option can be only positive or nothing, so why do you think it doesn't deserve to be a configurable?
(In reply to Alex Turbov from comment #4) > (In reply to Michał Górny from comment #3) > > As far as I can see, the only thing the configure switch does is adding > > '-std=c++11' to the compiler command-line. > > which is may affect both -- compile and run time performance. > anyway effect of this option can be only positive or nothing, so why do you > think it doesn't deserve to be a configurable? Because we don't use flags to control -std=. As far as I understand, new enough gcc enables C++11 features by default, doesn't it?
> > Because we don't use flags to control -std=. As far as I understand, new > enough gcc enables C++11 features by default, doesn't it? no! default is a C++03.
(In reply to Alex Turbov from comment #6) > > > > Because we don't use flags to control -std=. As far as I understand, new > > enough gcc enables C++11 features by default, doesn't it? > > no! default is a C++03. But it will be the default in a future version, correct? Anyway, doesn't changing the standard change ABI as well? I'm ready to add the flag but I'm wondering about the consequences. It may be necessary e.g. to enable it on all rev-deps (like Mesa) as well then.
> But it will be the default in a future version, correct? I suppose it will be a really far future... > Anyway, doesn't changing the standard change ABI as well? I'm ready to add > the flag but I'm wondering about the consequences. It may be necessary e.g. > to enable it on all rev-deps (like Mesa) as well then. I'm using this flag around a year already w/o any ABI clash...
Hmm, I'll do a run with abi-compliance-checker and report back.
I've just consulted the C++11 compatibility gcc doc [1] and checked the library ABI. Sadly, LLVM built with C++11 is partially ABI-incompatible with C++98 apps which means we can't 'simply' add it. If we're to enable the C++11 support, we will need to enable it on all reverse dependencies as well, and add USE=c++11 for them too, with sys-devel/llvm[c++11=] deps. [1]:http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-February/070772.html Well, we can't escape this ;)
Starting with llvm-3.5svn r202574, LLVM expects C+11 mode. [1] [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=f2d724c68662668b7c232ae0e5f018a82dfa0b3d I'd like to see C++11 enabled as soon as possible, to be possible verify C++11 support before final releases :)
I don't know if there's a point for USE=c++11 anymore. I guess we can just require C++11 starting with llvm-3.5.
Personally I'm not aware disadvantages using C++11. I'd guess few KBytes increase in size, maybe? I didn't found any interesting information about differences between llvm w/ and w/out C++11.
Since I had to recompile llvm on numerous machines, I'll temporarily force c++11 support and retest.
llvm-3.5 requires c++11 and the ebuild has a check for proper support, so I guess we can marked this one fixed with =llvm-3.5.0 :)
