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
