[Openmp-commits] [PATCH] LLVM OpenMP CMake Overhaul

Chandler Carruth chandlerc at google.com
Thu Jun 25 00:38:43 PDT 2015

On Tue, Jun 23, 2015 at 10:56 AM C Bergström <cbergstrom at pathscale.com>

> We may have conflicting goals or requirements then. I think it's a
> great thing to advance llvm, but I don't personally care what llvm
> defines as a default for OMP runtime. Anyone building libomp which
> isn't using it as part of llvm probably will feel the same way.

FWIW, while I think it is reasonable for the LLVM OpenMP runtime to
prioritize integrating with LLVM, I *also* think it is reasonable to
support other users of the runtime, just as we support non-LLVM and
non-Clang users of libc++. So I don't think these are conflicting at all.

> My original cmake, which was removed, exposed variables which allowed
> the user to define the flags. Am I mistaken that this is now being
> required again?

I'm pretty sure the user still has several variables they can use to define
flags; Jonathan mentioned these different mechanisms in his email.

> libomp_append(flags_local -std=c++0x
> When will this flag die? That's legacy shit from gcc from a long time
> ago..

I don't think you need to be so crude. Clang followed the same convention
until it was standardized, and has continued to follow it with c++1y and
C++1z... however I agree it may no longer be necessary.

> it should be c++11, which the minimum version of gcc required to
> build llvm supports.

You started off arguing for support of non-llvm builds of the runtime, a
goal I agree with. However, you can't then use LLVM's minimum versions of
host compilers as justification for what flag sets are supported. We should
make sure that the non-llvm builds of the runtime are all OK with the c++11
spelling. I certainly hope they are.

> runtime/cmake/LibompHandleFlags.cmake
> looks like a giant mess. This is exactly the reason it was the way it
> was before. Please work with others on the llvm side to get permission
> to for some middle-ground approach.

Do you have specific suggestions maybe? I'd like to see more comments,
grouping of related flags for various toolchains etc, but putting it in one
file vs. many files doesn't seem to preclude organizing and documenting
what is going on here.

> -------------
> Since you're spending all this time.. wouldn't those nasty perl
> scripts get in the way as well? (When will those die)

Many did with this change, and Jonathan called out that he was working on
the remainder. In fact there are comments about replacing expand-vars.pl in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20150625/7dd54e7e/attachment.html>

More information about the Openmp-commits mailing list