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

[Chandler Carruth]

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.

On Thu, May 28, 2015 at 7:32 AM Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

>      Why is it necessary to switch back the -fopenmp default rather
> than just have your users invoke -fopenmp=libgomp if they want to
> continue using a non-functional OpenMP under clang?


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.


> Certainly at this
> point the focus should be encouraging testing of the new llvm openmp
> library to identify corner cases that are still broken in the OpenMP
> 3.1 support promised for the 3.7 release. The openmp maintainers have
> been quite responsive to fixing this issues when reported on
> bugzilla...
>
> https://llvm.org/bugs/show_bug.cgi?id=23387
> https://llvm.org/bugs/show_bug.cgi?id=23392


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.


>
>
> Also switching the default isn't really the best way to nudge along
> the proposed the library name change to libomp if that really was the
> underlying impetus of this commit.
>

It was not. I tried to make subsequent patches simpler by baking in support
for the future name.

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.

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.


>         Jack
> ps What exactly is the utility of building non-functional openmp
> support with libgomp anyway? It seems rather pointless to enable
> openmp support in software if the generated code doesn't actually
> exercise its functionality.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150528/99a6f112/attachment.html>