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

[Chandler Carruth]

On Thu, Feb 20, 2014 at 2:57 AM, "C. Bergström" <cbergstrom at pathscale.com>wrote:

> On 02/20/14 05:43 PM, Chandler Carruth wrote:
>
>>
>> - 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.
>>
> We have some changes which should allow building with clang and also cmake
> build files to resolve a couple of your issues. I planned to create a pull
> request for Intel in the near future.


I so don't get this.

The project is no longer an Intel project. It is an LLVM project. The
development *must* take place as an LLVM project, or nothing else will
matter.

You could help formulate this process by submitting patches to the LLVM
project and committing them there. That *needs* to be the upstream to make
this a real, viable, open source effort.


> This should help make QA'ing libiomp5 easier.
>

This, of course, will be awesome. I look forward to better documentation as
well to clarify how to QA it. And tests with which to QA it.


> ----------
> While I agree with all your points - pragmatically there is probably very
> few real world clang + OMP users and the risk/impact is low.


This is simply false. I don't know why you think this. People here have
been using -fopenmp since the day they could link their binaries which
called out to an omp runtime library call. Yes, their pragmas don't do
anything, and their parallelism is terrible, but they really are critically
relying on the ability to build, link, and execute (single threaded)
programs with -fopenmp. Regressing a documented and readily available
feature of Clang with no warning and no prior release cycle where these
pieces were QA'ed and released is pretty... bad.


> I'd +1 this change since libiomp5 aligns with those who are actually
> working on the code, using it and reviewing it.


I've not seen how this aligns with Dmitri or Doug's usages and I think
they've done essentially all of the review. I know it doesn't align with
any of my users that are relying on -fopenmp not producing a link error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140220/ce508722/attachment.html>