On Wed, May 27, 2015 at 3:51 PM Chandler Carruth <chandl...@google.com> wrote:
> On Wed, May 20, 2015 at 12:02 AM Chandler Carruth <chandl...@google.com> > wrote: > >> I don't think this should have been committed yet. >> > > It's been a week without response. > > >> >> 1) The CMake build for the OpenMP stuff is still really broken and not >> well integrated with the rest of the LLVM project >> >> 2) Because of #1, I suspect very few users of Clang and LLVM have the >> libraries installed. >> >> 3) If they do, its still called 'libiomp' and not the final name that we >> planned for. >> > > None of these issues have been addressed. > > >> >> 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. >> >> 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. >> > > 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. > > > 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*. > > 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. > > 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'. > > 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. > > > 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. > > 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. > All of this was committed in r238389. > Sorry for the trouble, but we've had users broken by this for a week now. > > -Chandler >
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits