All,
Just a heads up that OpenMP 3.1 implementation in clang/llvm compiler
is fully complete.
Kudos to my colleague from Intel, Alexey Bataev, who wrote most of the code!
Apart of Alexey, many other people contributed to this effort; most
notably Alexander Musman (also from Intel), who implemented #pragma
simd; Mahesha S (then from AMD, now from Samsung), who wrote initial
patch that started it all; Intel Compiler QA team, that relentlessly
worked behind the scenes to test new developments all the way; and
last, but not least Richard Smith (Google), John McCall (Apple), Hal
Finkel (ANL), Dmitry Gribenko (Apple) and Doug Gregor (Apple) who did
a ton of code reviews and ensured high quality of the implementation.
Other people worth mentioning include Jim Cownie, Jack Howarth, Chris
Bergström and many members of OpenMP ARB who contributed with code
reviews, testing and general expertise.
Well done! -- and keep up the good work, to OpenMP 4.x and beyond! 
Yours,
Andrey Bokhanko
Congratulations! Would you like to add a blurb to the release notes
for the next release?
Thanks,
Hans
Is there a proposed patch yet for switching the -fopenmp support over
to the openmp library instead of libgomp? I realize the call to rename
the library may be complicating this process. Perhaps the switch of
the default library should be done first under the current libiomp5
name and that tested for a few days first before using follow on
patches to switch the library name to llomp or whatever. I would be
nice to no longer have to feed clang "-fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5".
Jack
It will come on next week.
I'd like to give a chance to everyone to raise their objections first.
Yours,
Andrey
So you plan on switching and enabling the openmp library defaults as
well as changing the openmp library name at the same time?
Jack
No, just changing defaults -- subject to code reviewers approval.
As I said before, I prefer to leave library naming to library pros.
Andrey
Andrey,
Any idea when the patch to enable openmp as the default for
-fopenmp will be posted to cfe-commits?
Jack
Jack,
Alexey [Bataev] promised to send it for review in a day or two. Then it should be approved by code reviewers, which might take some time.
andrey
ïÔÐÒÁ×ÌÅÎÏ Ó iPad
All,
Just a heads up that OpenMP 3.1 implementation in clang/llvm compiler
is fully complete.
Kudos to my colleague from Intel, Alexey Bataev, who wrote most of the
code!
Congratulations and many thanks to Alexey for all his hard work here, and
to every one else who has contributed to this effort. In recognition of his
work, commitment and expertise here, Alexey is code owner for our OpenMP
support going forward.
Jack,
Alexey [Bataev] promised to send it for review in a day or two. Then it should be approved by code reviewers, which might take some time.
andrey
Andrey,
There is one issue with the proposed patch at
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html
with regard to finding the installed libiomp5.dylib for linkage. If
the cmake build of llvm/clang/opemmp uses
-DCMAKE_INSTALL_PREFIX=/sw/opt/llvm-3.7, the -fopenmp option fails to
find the libiomp5.dylib installed in /sw/opt/llvm-3.7/lib for
linkage...
% clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
clang version 3.7.0 (trunk)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
"/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name omp_getEnvInfo.c
-mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 242 -v -dwarf-column-info
-fno-unique-section-names -resource-dir
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
/Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
-fopenmp -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-x c omp_getEnvInfo.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
x86_64-apple-darwin14.4.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
"/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
-macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-lSystem
ld: library not found for -liomp5
clang-3.7: error: linker command failed with exit code 1 (use -v to
see invocation)
The location of the installed libiomp5.dylib should always be in the
default library search path for the clang compilers.
Jack
Jack, this is not a problem of this patch, this a problem of your configuration. This patch uses standard clang machinery for locating libiomp5 library.
Best regards,
Alexey Bataev
Jack, this is not a problem of this patch, this a problem of your
configuration. This patch uses standard clang machinery for locating t
libiomp5 library.
Best regards,
Alexey Bataev
Software Engineer
Intel Compiler Team
Andrey,
I disagree in that currently the clang machinery only expects to
have to look in the subdirectory lib/clang/3.7.0/lib/darwin for shared
libraries. Considering that libc++ is the only other shared library in
llvm which clang had to track in the past, this issue hasn't really
been addressed in the past. It is clearly wrong for clang to allow
libiomp5.dylib to be installed in a buried subdirectory using the
CMAKE_INSTALL_PREFIX cmake option which clang then doesn't know about
when attempting to link -liomp5. I am not saying the patch itself is
flawed but rather than there needs to be a discussion about the
expected search path for libraries in clang vs the installed locations
of libiomp5. Currently we have a gap where the CMAKE_INSTALL_PREFIX
cmake option allows libiomp5.dylib to be installed in a location that
clang is unaware of which is clearly broken behavior.
Jack
Jack, this is not a problem of this patch, this a problem of your
configuration. This patch uses standard clang machinery for locating t
libiomp5 library.
Best regards,
Alexey Bataev
Software Engineer
Intel Compiler Team
Andrey,
I would also note that libc++ is an odd duck since AFAIK in-tree
builds of libc++ are still discouraged so it tends to be built and
installed independently of the rest of the llvm build tree, Outside of
libc++, clang currently only expects to find shared libraries from the
llvm cmake build in the lib/clang/3.7.0/lib/darwin subdiirectory. So
openmp actually is the first shared library (used by a clang compiler
option) which is installed outside of the lib/clang/3.7.0/lib/darwin
subdirectory. Again this isn't a defect in the -fopenmp patch but
rather a deficiency in the current clang library search path vs the
possible install locations used with the CMAKE_INSTALL_PREFIX cmake
option.
Jack