[PATCH] Enable C++11

[Iain Sandoe]

Hi David,

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 ..

Iain