[PATCH] [OPENMP] Replace libgomp by libiomp5 in driver

[Chandler Carruth]

On Thu, Feb 20, 2014 at 2:23 AM, Dmitri Gribenko <gribozavr at gmail.com>wrote:

>   We just used to link in libgomp for compatibility with gcc, is this
> correct?  (For example, some object files could be compiled with GCC with
> OpenMP, while the rest of the program could be compiled with clang and
> linked with 'clang -fopenmp'.)
>
>   If it is so, I think the change is good, the users can get the previous
> behavior by specifying the required libraries manually.
>

I really disagree, unless I misunderstand the change entirely.

Today, when users get Clang on Linux, they likely already have libgomp
installed much as they have libstdc++ installed. We don't even vaguely
document how to build or install libiomp5, much less is that common
practice when installing a Clang and LLVM based toolchain. As such, this
essentially regresses every user if -fopenmp on Linux.

If you think this is totally fine for Darwin, Dmitri, I can't *really*
argue as I don't work on Darwin heavily, but it seems completely crazy to
me to require a *completely* undocumented library installation process,
with no tests, and no ability to self host with Clang and have full feature
support.

Note that we don't have a single build bot set up externally that tests
libiomp5 AFAIK. In fact, the situation is much more dire than that:

- 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.
- 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.
- 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.
- 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.
- 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!
- No part of this library has gone through an LLVM release process either,
not even as a "new" or "beta" project.

While I'm very glad that the basic source code for this library was
contributed to the LLVM project, it is *not* an active part of the project,
it is *not* a reasonable requirement that users install and have as part of
their Clang toolchain, and it is *not* a production quality open source
piece of software. Thus I cannot support it as being the default library to
link in under *any* circumstances, and I absolutely object to it being the
default under Linux.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140220/f70c9bc1/attachment.html>