<div dir="ltr">On Thu, Apr 30, 2015 at 10:23 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><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"> The current test suite status on x86_64-apple-darwin14, with the proposed patch from <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html</a> applied to current cfe trunk, is quite respectable....<br><br>Summary:<br>S Number of tested Open MP constructs: 62<br>S Number of used tests: 123<br>S Number of failed tests: 16<br>S Number of successful tests: 107<br>S + from this were verified: 106<br><br>Normal tests:<br>N Number of failed tests: 8<br>N + from this fail compilation: 1<br>N + from this timed out 0<br>N Number of successful tests: 54<br>N + from this were verified: 54<br><br>Orphaned tests:<br>O Number of failed tests: 8<br>O + from this fail compilation: 0<br>O + from this timed out 0<br>O Number of successful tests: 53<br>O + from this were verified: 52<br><br>for 'make ctest' using "-fopenmp=libiomp5 -Xclang -fopenmp=libiomp5 -L/sw/opt/llvm-3.7.0/lib -lm -O3". Whereas for libgomp, the results are pitiful....<br><br>Summary:<br>S Number of tested Open MP constructs: 62<br>S Number of used tests: 123<br>S Number of failed tests: 30<br>S Number of successful tests: 93<br>S + from this were verified: 12<br><br>Normal tests:<br>N Number of failed tests: 15<br>N + from this fail compilation: 0<br>N + from this timed out 0<br>N Number of successful tests: 47<br>N + from this were verified: 6<br><br>Orphaned tests:<br>O Number of failed tests: 15<br>O + from this fail compilation: 0<br>O + from this timed out 0<br>O Number of successful tests: 46<br>O + from this were verified: 6<br><br></div></blockquote><div><br></div>For additional context, the OpenMP3.1_Validation results for libgomp using the FSF gcc 5.1.0 compiler on x86_64-apple-darwin14 are...<br><br>Summary:<br>S Number of tested Open MP constructs: 62<br>S Number of used tests: 123<br>S Number of failed tests: 7<br>S Number of successful tests: 116<br>S + from this were verified: 95<br><br>Normal tests:<br>N Number of failed tests: 3<br>N + from this fail compilation: 0<br>N + from this timed out 0<br>N Number of successful tests: 59<br>N + from this were verified: 48<br><br>Orphaned tests:<br>O Number of failed tests: 4<br>O + from this fail compilation: 0<br>O + from this timed out 0<br>O Number of successful tests: 57<br>O + from this were verified: 47<br><br>So the current results for libiomp5 are very close to matching those for the FSF gcc compiler with libgomp in terms of the number of passed tests while libiomp5 already exceeds libgomp for the number of verified tests.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">when using "-fopenmp=libgomp -Xclang -fopenmp=libgomp -L/sw/lib/gcc5/lib -lm -O3 -Wl,-no_compact_unwind". So we can't get much more broken that the current behavior with libgomp.<span class=""><font color="#888888"><br> Jack<br><div class="gmail_extra"><div class="gmail_extra"><font face="Menlo"><span style="font-size:11px"><br></span></font></div></div></font></span><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Thu, Apr 30, 2015 at 9:49 AM, Andrey Bokhanko <span dir="ltr"><<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">All,<div><br></div><div>I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp.</div><div><br></div><div>For reference, the previous discussion is accessible there: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461</a></div><div><br></div><div>We are very close to getting *full* OpenMP 3.1 specification supported in clang (only one (!) clause is not implemented yet, and the patch is already sent for review today: <a href="http://reviews.llvm.org/D9370" target="_blank">http://reviews.llvm.org/D9370</a>). This implementation generates Intel API library calls; thus, it can't be used with libgomp and it is simply logical to link a compatible runtime (libiomp) instead.</div><div><br></div><div>Last time Chandler objected against doing this, and gave a good (and proper!) scolding. Let me quote his objections along with updates on current state of things:</div><div><br></div><div><p class="MsoNormal">- 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.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Now it is actively developed by several members of the community. Changes are committed in small patches. See "openmp-commits" mailing list (<a href="http://lists.cs.uiuc.edu/pipermail/openmp-commits/" target="_blank">http://lists.cs.uiuc.edu/pipermail/openmp-commits/</a>) for details.</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">- 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.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">Nowadays the traffic, while less than on llvm-dev mailing list (understandably so :-)) is far from being "zero". Discussions happen all the time. See the list archives for details (<a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/" target="_blank">http://lists.cs.uiuc.edu/pipermail/openmp-dev/</a>).</p><p class="MsoNormal"><br></p><p class="MsoNormal">- 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.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">This is fixed.</p><p class="MsoNormal"><br></p><p class="MsoNormal">- 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.</p><p class="MsoNormal"><br></p><p class="MsoNormal">The build system is full re-written and now cmake-based. The last remaining step (integration into overall llvm build system) is about to be done by any day now (<a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500" target="_blank">http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500</a>).</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">- 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!</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">UofHouston contributed a comprehensive test suite: <a href="http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/" target="_blank">http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/</a>.</p><p class="MsoNormal"><br></p><p class="MsoNormal">- No part of this library has gone through an LLVM release
process either, not even as a "new" or "beta" project.</p><p class="MsoNormal"><br></p><p class="MsoNormal">The whole library is a part of two last llvm releases: 3.5 and 3.6.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Thus, I believe all of Chandler's concerns are resolved, and it is finally a good time time to switch to libiomp as default OpenMP library.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Anyone who supports this?</p><p class="MsoNormal"><br></p><p class="MsoNormal">Anyone who disagrees?</p><p class="MsoNormal"><br></p><p class="MsoNormal">Chandler?</p></div><div><br></div><div>Yours,</div><div>Andrey Bokhanko</div><div>==============</div><div>Software Engineer</div><div>Intel Compiler Team</div><div>Intel</div><div><br></div></div>
<br></div></div><span class="">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div>