Doug,
Ok, I'll add something like this.
Best regards,
Alexey Bataev
=============
Software Engineer
Intel Compiler Team
Intel Corp.
25.02.2014 2:02, Douglas Gregor пишет:
On Feb 24, 2014, at 2:00 AM, Alexey Bataev <[email protected]> wrote:
Hello all,
I agree with Hal and I'll modify the patch. I'm going to add option
-fopenmp-libiomp5 which will make driver to use libiomp5 instead of libgomp.
libgomp will remain the default library.
Any thoughts or objections?
I think this is the right direction. How about -fopenmp=libiomp5, the same way
we handle -stdlib=(libc++ or libstdc++)?
- Doug
Best regards,
Alexey Bataev
=============
Software Engineer
Intel Compiler Team
Intel Corp.
20.02.2014 16:32, Hal Finkel пишет:
----- Original Message -----
From: "Chandler Carruth" <[email protected]>
To: "C. Bergström" <[email protected]>
Cc: [email protected], "Douglas Gregor"
<[email protected]>, "Hal
Finkel" <[email protected]>, "Dmitri Gribenko" <[email protected]>,
[email protected], "a bataev"
<[email protected]>, "llvm cfe" <[email protected]>
Sent: Thursday, February 20, 2014 5:15:54 AM
Subject: Re: [PATCH] [OPENMP] Replace libgomp by libiomp5 in driver
On Thu, Feb 20, 2014 at 2:57 AM, "C. Bergström" <
[email protected] > 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.
I agree that changing the default at this point is premature; there are users
following trunk who rely on the existing behavior, and they'll see no benefit
from the current change. On the other hand, we need the ability to link against
our own runtime library in order to start adding CodeGen support, so we do need
this change, it just does not need to be the default yet.
Why don't we add a -fopenmp-lib=[gomp|iomp] or -fopenmp-type or flavor or
whatever (I don't have a strong opinion about the naming), and base things off
of that? In the future, we can change the default, and we can leave CodeGen
support disabled when not targeting our own runtime.
-Hal
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
