[cfe-dev] moving the clang-omp merge along

[Alp Toker]

Thanks for the summary Andrey.

The underlying problem For the OpenMP *runtime* is really lack of 
visibility and sidelining on the openmp-dev list.

It's absolutely critical to close down the low-volume openmp-dev list 
and fold the subscribers into one of the more active mailing lists, 
either llvm-dev or cfe-dev.

Until that's done the patches won't get review from the mainstream LLVM 
developer community, build system experts won't join in etc.

Alp.



On 29/05/2014 16:46, Andrey Bokhanko wrote:
> All,
>
> 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: 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/thread.html#73025 
> started by Jack. I thought he means libiomp when saying "openmp 
> support" -- apparently, I was mistaken. Hence the confusion.
>
> After so many talks with Chandler, I know very well that upstreaming 
> full OpenMP support is a long way to go. :-)
>
> Also, the whole desire to put the library into 3.5 release is a 
> responce to the criticism expressed by Chandler in this message: 
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/099477.html.
>
> While we are on the topic, let me update on some other things 
> happening in responce to other issues highlighted by Chandler:
>
> - This library is not being developed as an active part of the LLVM
> community, even if it is checked into SVN as part of the LLVM project and
> under its license. See r197914 where there is a code drop of many months
> worth of development with *no* change log, attribution, information, or
> other participation in any part of the community.
>
> 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.
>
> Take a look at the recent activity in openmp-dev mailing list. More to 
> come.
>
>
> - There has been essentially *zero* discussion with the rest of the clang
> or llvm community about this library. There are separate mailing lists
> which have nearly no traffic since the code drop.
>
> Take a look at this month's messages: 
> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-May/thread.html. In 
> general, as more people get interested, more traffic became generated. 
> It's a chicken and egg problem...
>
> - There has been no effort to make this library even work properly with
> Clang as a host compiler. See the copious notes that only Clang 3.3 is
> supported, and that not full featured.
>
> It is buildable with clang now. Moreover, regular buildbots, with both 
> gcc and clang, are running:
>
> http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian
> http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian
>
> - The build system is totally disjoint from LLVM's, in fact it is an
> entirely custom Perl build system that is unlike anything in use by the
> LLVM project.
>
> We started to work on improving build system. Stay tuned.
>
> - There are *zero tests* in the open source repository!!!! This is even
> called out in the original submission and on the primary website. We 
> simply
> *cannot* ship and link against a runtime library which has no tests!
>
> University of Houston contributed OpenUH test suite: 
> http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html. Sunita 
> Chandrasekaran from the University works on integrating this suite 
> into LLVM test system.
>
> BTW, any advice with how to approach this would be *much* appreciated!
>
> - No part of this library has gone through an LLVM release process either,
> not even as a "new" or "beta" project.
>
> Aha! So, you support inclusion of openmp (library, not compiler) in 
> 3.5 as well? :-)
>
> Andrey
>
>
>
> On Thu, May 29, 2014 at 2:19 AM, Jack Howarth 
> <howarth.mailing.lists at gmail.com 
> <mailto:howarth.mailing.lists at gmail.com>> wrote:
>
>     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.
>                Jack
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
http://www.nuanti.com
the browser experts