<div dir="ltr">All,<br><br>To clarify, what I meant is getting OMP runtime library (not clang-omp branch!) as a part of 3.5 release. I specifically referred to this thread: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/thread.html#73025">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/thread.html#73025</a> started by Jack. I thought he means libiomp when saying "openmp support" -- apparently, I was mistaken. Hence the confusion.<br>
<br>After so many talks with Chandler, I know very well that upstreaming full OpenMP support is a long way to go. :-)<br><br>Also, the whole desire to put the library into 3.5 release is a responce to the criticism expressed by Chandler in this message: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/099477.html">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/099477.html</a>.<br>
<br>While we are on the topic, let me update on some other things happening in responce to other issues highlighted by Chandler:<br><br>- This library is not being developed as an active part of the LLVM<br>community, even if it is checked into SVN as part of the LLVM project and<br>
under its license. See r197914 where there is a code drop of many months<br>worth of development with *no* change log, attribution, information, or<br>other participation in any part of the community.<br><br>This is changing, and many developers joining the whole OpenMP in clang support effort. I can say that Michael Wong and many of his colleagues from IBM are involved; Eric Stotzer and his colleagues from TI are involved; Barbara Chapman and her group from UofHouston is involved; Guansong Zhang from AMD is involved. Obviously, Hal Finkel, Chris Bergstrom, Steve Noonan and many others continue to be actively involved as well.<br>
<br>Take a look at the recent activity in openmp-dev mailing list. More to come.<br><br><br>- There has been essentially *zero* discussion with the rest of the clang<br>or llvm community about this library. There are separate mailing lists<br>
which have nearly no traffic since the code drop.<br><br>Take a look at this month's messages: <a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-May/thread.html">http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-May/thread.html</a>. In general, as more people get interested, more traffic became generated. It's a chicken and egg problem...<br>
<br>- There has been no effort to make this library even work properly with<br>Clang as a host compiler. See the copious notes that only Clang 3.3 is<br>supported, and that not full featured.<br><br>It is buildable with clang now. Moreover, regular buildbots, with both gcc and clang, are running:<br>
<br><a href="http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian">http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian</a><br><a href="http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian">http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian</a><br>
<br>- The build system is totally disjoint from LLVM's, in fact it is an<br>entirely custom Perl build system that is unlike anything in use by the<br>LLVM project.<br><br>We started to work on improving build system. Stay tuned.<br>
<br>- There are *zero tests* in the open source repository!!!! This is even<br>called out in the original submission and on the primary website. We simply<br>*cannot* ship and link against a runtime library which has no tests!<br>
<br>University of Houston contributed OpenUH test suite: <a href="http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html">http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html</a>. Sunita Chandrasekaran from the University works on integrating this suite into LLVM test system.<br>
<br>BTW, any advice with how to approach this would be *much* appreciated!<br><br>- No part of this library has gone through an LLVM release process either,<br>not even as a "new" or "beta" project.<br>
<br>Aha! So, you support inclusion of openmp (library, not compiler) in 3.5 as well? :-)<br><br>Andrey<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 2:19 AM, Jack Howarth <span dir="ltr"><<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> <font face="Calibri, sans-serif"><span style="font-size:15px">Andrey Bokhanko expressed interest in getting the clang-omp merge done in time for the 3.5 release but wants guidance on the process. I suggested starting with the creation a new clang-omp branch upstream rebased on clang trunk for generation of merge patch. Unfortunately merging the current changes from the clang-omp (based on clang 3.4) to a clang-omp (based on clang trunk) looks very difficult as selective patches have been committed into clang trunk from clang-omp and don't appear to have been kept synchronized with the current changes from upstream. Does anyone know if these new files from previous commits out of clang-omp contain any local changes which haven't been back ported to clang-omp? It would seem that postponing this merge will just make the process harder as time goes on if selective merges from clang-omp into clang trunk continue in the interim. Hopefully the folks who did the original selective commits would help detangle this mess.</span></font><span class="HOEnZb"><font color="#888888"><div>
<font face="Calibri, sans-serif"><span style="font-size:15px"> Jack</span></font></div></font></span></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>