r237769 - [OPENMP] -fopenmp enables OpenMP support (fix for http://llvm.org/PR23492)

[Chandler Carruth]

On Wed, May 20, 2015 at 12:02 AM Chandler Carruth <chandlerc at 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.

Sorry for the trouble, but we've had users broken by this for a week now.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150527/773c7f8f/attachment.html>