[PATCH] Enable C++11
iain at codesourcery.com
Tue Jan 7 12:00:32 PST 2014
On 7 Jan 2014, at 18:54, David Fang wrote:
>>> I've actually created a powerpc-darwin8-rel-3.4 branch that tracks
>>> 'release_34', and tried to backport some of the fixes that missed the 3.4
>> Cool, it sounds like these should definitely be back-ported without issue
>> and unblock you. That would then allow you to use Clang as a baseline for
>> subsequent builds.
>>> Depending on how far trunk has diverged from the 3.4 brach, we *may* be able to backport those fixes as well. I will certainly make an effort.
>> Similarly, once you have a working host by backporting these, you should be
>> fine to use C++11 features no?
> The other remaining major hurdles include fixing the powerpc-darwin ABI (Iain and I are testing his data-layout/alignment patches), fixing FDE generation for EH-frames (patch approved and commit pending), and getting a working libc++ on powerpc-darwin to support C++11. libc++ built against system's libsupc++ at -O0 with a stage-1 clang still exhibits many fatal errors, a subject for another thread. Another wish is to fix issues that block compiling with -O1 (e.g. bug 14579). Compiling stage-3 at -O0 on my old h/w takes 3 days, painfully slow for debug/test turn-around. That summarizes our current priorities.
there are certainly additional ABI & reloc breakages to be addressed (definitely on ppc, perhaps less likely on legacy i686).
the problem is that this is ('volunteer' effort - so we can't guarantee to meet any particular schedule.
for my part, I am not too concerned that any of the patches that we cook up to solve these legacy darwin (my interest extends to *-darwin9) issues would be hard to back-port to 3.4 (at least not over shortish period).
I would recommend concentrating on identifying any patches outside the set we 'understand' and making sure that those are applied to your local 3.4 branch as you noted above …
… as discussed noted off-list, it's also relatively easy to use gcc-4.8 as a bootstrap compiler (OK, possibly inconvenient if you were not intending to build it anyway) - but not, fundamentally, a show-stopper.
> Was there a consensus about what C++11 features would be allowed/encouraged in the llvm/clang code base? perhaps part of a C++ style-guide?
I'm sure this question is of general interest ..
More information about the cfe-commits