+1 Yours, Andrey
On Thu, Feb 20, 2014 at 4:32 PM, Hal Finkel <[email protected]> wrote: > ----- 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 > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
