<div dir="ltr">I think more threads makes this discussion much harder to follow. Please either keep this in the review thread of r237769 or the new review thread for r238389.<br><br><div class="gmail_quote">On Thu, May 28, 2015 at 7:32 AM Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">     Why is it necessary to switch back the -fopenmp default rather<br>
than just have your users invoke -fopenmp=libgomp if they want to<br>
continue using a non-functional OpenMP under clang?</blockquote><div><br></div><div>I don't have the luxury of forcing all of my users to re-write their compiler flags. Also, doing this would break their use of GCC. The goal of Clang is to be a reasonably GCC compatible compiler, and this would move us directly away from this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Certainly at this<br>
point the focus should be encouraging testing of the new llvm openmp<br>
library to identify corner cases that are still broken in the OpenMP<br>
3.1 support promised for the 3.7 release. The openmp maintainers have<br>
been quite responsive to fixing this issues when reported on<br>
bugzilla...<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23387&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=P9rDdnNlvCULTAPeNwu6WY3EpbN9neEqFV1js6cmTIM&s=61LwjZpMI38ZN5bjQvZ8IWZ84LHfdY1vwTyKTKpmJ2Y&e=" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=23387</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23392&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=P9rDdnNlvCULTAPeNwu6WY3EpbN9neEqFV1js6cmTIM&s=vC6C4tdbWUNDqbXc4mLPK5he_7aA4sci8O3hLWSxLRk&e=" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=23392</a></blockquote><div><br></div><div>Yes, but we need to have the build, test, and distribution issues sorted out. I think they are actively working on these issues, and I'm pleased with the progress, but we need to keep trunk Clang working until they get resolved.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Also switching the default isn't really the best way to nudge along<br>
the proposed the library name change to libomp if that really was the<br>
underlying impetus of this commit.<br></blockquote><div><br></div><div>It was not. I tried to make subsequent patches simpler by baking in support for the future name.</div><div><br></div><div>This commit was about reverting to green. Today, I have a very large body of users relying on using '-fopenmp' with both Clang and GCC. They can live with serial execution using Clang, but they can't live with build breaks. Until we can package and distribute the openmp runtime along with the rest of our toolchain, switching the default of '-fopenmp' is, IMO, premature.</div><div><br></div><div>I said all of this in the code review of the patch which flipped the default, and heard no objections or disagreement from anyone in the community until now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        Jack<br>
ps What exactly is the utility of building non-functional openmp<br>
support with libgomp anyway? It seems rather pointless to enable<br>
openmp support in software if the generated code doesn't actually<br>
exercise its functionality.<br></blockquote><div><br></div><div>OpenMP allows both pragmas that generate parallelism and explicit library APIs that can be called by user code. Without linking *some* OpenMP runtime, the code cannot link much less run. However, ignoring the pragmas is *designed* to provide serial equivalent execution semantics (with the task stuff being a notably difference). Given that, it may be a low performance approach, but it does actually function correctly and we have very many users relying on exactly this. </div></div></div>