[Openmp-commits] [Openmp-dev] Large Refactor of CMake build system

[C Bergström]

On Tue, Jul 21, 2015 at 10:12 AM, Peyton, Jonathan L
<jonathan.l.peyton at intel.com> wrote:
> First, I want the code to reach as many people as possible including pathcc users.  So on my own time, I have downloaded the Pathscale compiler from: http://www.pathscale.com/ekopath-compiler-suite which I did not know was open sourced, and tried to build libomp with pathcc on Linux, x86_64 (Yes, still Intel world in terms of architecture, but your original complaint suggested it was with the compiler) with Chandler's latest flag checks and succeeded with the log of the entire process attached.
> There's numerous warnings about deprecated register storage (-Wdeprecated-register), and with some further investigation this is caused by the -std=c++11 flag and as I recall, Chris, you were the driving force behind getting that changed.  I don't see either -Wno-deprecated-register or -Wdeprecated-register flag available for the open sourced pathcc so I don't see how to fix that warning even though pathcc's warning message suggests it exists.  It's certainly no showstopper.
>
> I’ll reiterate once more.  I feel the changes should stay.

#1 The patch fixed the problem. If you feel it's a good fix then push
it. I wasn't clear on the exact behavior.
--------
In response to your personal efforts - I apologize as some of the
information on our website may not be clear.

EKOPath 4 was fully open source - EKOPath 5+ has returned to a closed model.
The EKOPath page contains a link for a nightly build. If you adjusted
the date in the URL some of the issues you see may be fixed already.

Without that patch it tries to link using libgcc-static. (Which our
compiler doesn't support and will error on)
------------
Historically, "we" (PathScale) have been the 1st to adopt usage of the
Intel OMP runtime afaik. This dates back to before it existed inside
the llvm community. We had to mirror the source on github and
basically fork because there wasn't an easy way to handle passing the
changes up/down. As this process of integration with llvm has evolved
- we've continued to submit and work with others on the cmake build
system. If other compilers are compatible with gcc link flags - I
doubt they would see a problem. Long term I'd be fine and probably
prefer you to just detect the PathScale compiler and not set anything.
This applies across *ALL* platforms. (OSX, Solaris, Win.. etc)

I've contributed to the Aarch64 port and will continue to send patches
if upstream is friendly. What I'm seeing now is great on one side, but
not really cool on the other. The 3.7 Release branch should be stable.
If you really want to test against a variety of places for non-llvm
builds I can help facilitate that.

I hope this is resolved very soon.