<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 2:57 AM, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 02/20/14 05:43 PM, Chandler Carruth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- 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.<br>
- 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.<br>
</blockquote></div>
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.</blockquote><div><br></div><div>
I so don't get this.</div><div><br></div><div>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.</div><div><br></div><div>
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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 This should help make QA'ing libiomp5 easier.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
----------<br>
While I agree with all your points - pragmatically there is probably very few real world clang + OMP users and the risk/impact is low.</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'd +1 this change since libiomp5 aligns with those who are actually working on the code, using it and reviewing it.</blockquote>
</div><br>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.</div>
</div>