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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
