[libdispatch-dev] lib dispatch worker threads may loop depending on compiler optimization

[Joakim Johansson]

On 13 sep 2011, at 10:45, Jordan K. Hubbard wrote:
> On Sep 12, 2011, at 11:06 PM, Joakim Johansson wrote:
> 
>> I definitely agree that blocks are very nice (as is clang, which I hope that we will be able to use pending ability to build our C++ code, which was still lacking last time we tested). 
> 
> Just to chime in with Jean-Daniel - what svn tag of clang did you last test against, if I might ask?

Sure, it was last November on OS X actually, it was "Apple clang version 2.0 (tags/Apple/clang-121.4) (based on LLVM 2.9svn)”. On Solaris we’ve used 2.8 ("tags/RELEASE_28 123229”) for the GCD testing.

We should have filed a bug report (and will do so after trying out with trunk going forward), right now the only feedback I could find was a short comment 'Not usable yet. Too aggressive in template code analysis.’… Will follow up internally.

>  LLVM/clang itself (which conains a truly enormous amount of C++ code) passed the self-hosting milestone quite some time back and has been "maturing rapidly" towards "full C++ support" (whatever the heck that may mean at any time).  It might not be a bad idea to re-test against trunk, if that's possible, since it would at least let you know whether gcc was really a short-term or a medium-term problem.  

Absolutely, it is already on our roadmap to do so going forward… 

> Seems a good idea regardless and, even if the FSF doesn't take the patch(s) back, they can be used to create a gcc-kludge train off of whatever gcc $version you're following with the happy knowledge that it's only short term anyway because clang and its devilishly tempting support for blocks is calling. ;-)

You are preaching to the choir ;-) 

The only problem of not doing ‘a’ (workaround in the GCD source base), is that having a gcc-kludge train would of course work for us internally, but it would still make GCD less accessible if one is willing to live with the subset of functionality provided by gcc - I can see that it is not obvious whether the FSF even views this as a bug (Paolo started the discussion at http://gcc.gnu.org/ml/gcc/2011-09/msg00088.html which is still ongoing…)

Thanks,

Joakim