[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp

[Jack Howarth]

     The current test suite status on x86_64-apple-darwin14, with the
proposed patch from
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html
applied to current cfe trunk, is quite respectable....

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:                123
S Number of failed tests:              16
S Number of successful tests:          107
S + from this were verified:           106

Normal tests:
N Number of failed tests:              8
N + from this fail compilation:        1
N + from this timed out                0
N Number of successful tests:          54
N + from this were verified:           54

Orphaned tests:
O Number of failed tests:              8
O + from this fail compilation:        0
O + from this timed out                0
O Number of successful tests:          53
O + from this were verified:           52

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....

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:                123
S Number of failed tests:              30
S Number of successful tests:          93
S + from this were verified:           12

Normal tests:
N Number of failed tests:              15
N + from this fail compilation:        0
N + from this timed out                0
N Number of successful tests:          47
N + from this were verified:           6

Orphaned tests:
O Number of failed tests:              15
O + from this fail compilation:        0
O + from this timed out                0
O Number of successful tests:          46
O + from this were verified:           6

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.
           Jack

On Thu, Apr 30, 2015 at 9:49 AM, Andrey Bokhanko <andreybokhanko at gmail.com>
wrote:

> All,
>
> I'd like to resurrect the discussion on replacing libgomp with libiomp as
> the default OpenMP runtime library linked with -fopenmp.
>
> For reference, the previous discussion is accessible there:
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461
>
> 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: http://reviews.llvm.org/D9370). 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.
>
> 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:
>
> - 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.
>
>
> Now it is actively developed by several members of the community. Changes
> are committed in small patches. See "openmp-commits" mailing list (
> http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details.
>
>
> - 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.
>
>
> 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 (
> http://lists.cs.uiuc.edu/pipermail/openmp-dev/).
>
>
> - 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.
>
>
> This is fixed.
>
>
> - 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.
>
>
> 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 (
> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500).
>
>
> - 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!
>
>
> UofHouston contributed a comprehensive test suite:
> http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/.
>
>
> - No part of this library has gone through an LLVM release process either,
> not even as a "new" or "beta" project.
>
>
> The whole library is a part of two last llvm releases: 3.5 and 3.6.
>
>
> 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.
>
>
> Anyone who supports this?
>
>
> Anyone who disagrees?
>
>
> Chandler?
>
> Yours,
> Andrey Bokhanko
> ==============
> Software Engineer
> Intel Compiler Team
> Intel
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/9c27d7da/attachment.html>