<div dir="ltr"><br><br><div class="gmail_quote">On Wed, May 27, 2015 at 3:51 PM Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">On Wed, May 20, 2015 at 12:02 AM Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't think this should have been committed yet.<br></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>It's been a week without response.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>1) The CMake build for the OpenMP stuff is still really broken and not well integrated with the rest of the LLVM project<div><br></div><div>2) Because of #1, I suspect very few users of Clang and LLVM have the libraries installed.</div><div><br></div><div>3) If they do, its still called 'libiomp' and not the final name that we planned for.</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>None of these issues have been addressed.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Now, I have users that have libgomp installed and have been successfully using '-fopenmp' to link against it for over a year in order to satisfy the runtime library calls against its API. With this patch, all of them are broken because we haven't yet been able to build and deploy the LLVM OpenMP library to them, largely because of the above problems.</div><div><br></div><div>I'd much rather this not go in yet, or at least expose some CMake variable to revert to the old behavior so we can continue supporting users that had a working setup before this patch and now are broken.</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>This at least got partially fixed, but that fix didn't work because this change has another, *much* more significant change that was never mentioned in the review or the change description.</div><div><br></div><div><br></div><div>Before this change, using '-fopenmp' as a flag to GCC enabled OpenMP and linked against libgomp. Using '-fopenmp' as a flag to Clang linked against libgomp, but *did not enable any OpenMP language features*.</div><div><br></div><div>Let me restate that because it took me a couple of tries to really get this: everyone using '-fopenmp' as a flag to Clang has had working compiles but *zero* actual usage of Clang's OpenMP support until this commit.</div><div><br></div><div>As a consequence, any bugs or problems in Clang's OpenMP language support would only get diagnosed of users of Clang were explicitly passing '-fopenmp=libiomp5'.</div><div><br></div><div>Also as a consequence, prior to this patch '-fopenmp' as a flag to Clang enabled a tested, working, but *very* slow OpenMP implementation combined with libgomp. Clang nicely ignored every pragma, and generated serial code. After this change, users got a broken build no matter what they did. There is no easy way to recover the old behavior because now the language level facilities are enabled, but there is no hook to disable *code generation* separately from the parsing and semantic analysis.</div><div><br></div><div><br></div><div>So, given the silence here and the amount of work left to allow random Jane developer to grab LLVM and Clang and necessary runtimes to build, install, and use a toolchain supporting OpenMP, I'm going to take the default back.</div><div><br></div><div>I'm also going to add infrastructure to make it easy to use '-fopenmp=libgomp' or a CMake variable to retain the previous behavior. I would love to have an enhancement of this that would actually *only* remove the IR generation for the openmp constructs, but I don't have time to implement that.</div></div></div></blockquote><div><br></div><div>All of this was committed in r238389.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Sorry for the trouble, but we've had users broken by this for a week now.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-Chandler</div></div></div></blockquote></div></div>