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

[Chandler Carruth]

On Wed, May 27, 2015 at 3:51 PM Chandler Carruth <chandlerc at google.com>
wrote:

> 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.
>

All of this was committed in r238389.


> 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/20150528/0eb6244c/attachment.html>