Since 3.7 llvm can use OpenMP with the help of sys-libs/libomp indtead of the GCC-bundled libgomp, which doesn't work. Unfortunately because of $reasons upstream hardcoded the default to be libgomp, so one always has tro specify -fopenmp=libomp to point clang/llvm at the correct OpenMP runtime lib. This makes interop with gcc more difficult than necessary. Just using -fopenmp should do the right thing. Apparently this default can be changed through --with-clang-default-openmp-runtime when llvm is built via autoconf; however the ebuild uses cmake, and I have not yet found a way to accomplish this (or even where the cmake build sets this value), hence this RFE. Reproducible: Always
Could I please have a comment whether this is reasonable enhancement or somehow a bad idea?
I'm afraid I have no idea ;-). Reading your comment, is libgomp support generally broken or are you thinking of a specific case when it doesn't work?
(In reply to Michał Górny from comment #2) > I'm afraid I have no idea ;-). Reading your comment, is libgomp support > generally broken or are you thinking of a specific case when it doesn't work? Thanks for reading. :) As far as I could tell when trying to make "Hello OpenMP World" run, linking against libgomp (what happens by default) doesn't work at all. The runtime isn't initialized and it just runs single-threaded. When using clang with -fopenmp=libomp it immediately works as expected, initializing the runtime and using all cores. Obviously the program is then also linked against libomp, but that's expected and OK. I'll attach a sample program to demonstrate.
Created attachment 418408 [details] Trivial OpenMP "Hello World" example
Apparently upstream wanted some feedback first before switching the default: https://bugs.gentoo.org/show_bug.cgi?id=559588#c3 http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html#openmp-support At that time, adding openmp support, I followed this. I'd say as support was brand new in 3.7, we could wait for 3.8 and see there if we change from upstream defaults
(In reply to Bernard Cafarelli from comment #5) > Apparently upstream wanted some feedback first before switching the default: > https://bugs.gentoo.org/show_bug.cgi?id=559588#c3 > http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html#openmp- > support > > At that time, adding openmp support, I followed this. I'd say as support was > brand new in 3.7, we could wait for 3.8 and see there if we change from > upstream defaults That's a reasonable compromise, thanks! Maybe that would also be a good time to introduce USE="openmp" just like gcc has, to control the initial dependency on libomp. I'll leave this open until then.
I'd rather avoid use flags for runtime dependencies. This will make people think they need to rebuild llvm for openmp support, and rebuilding llvm is well... quite time consuming.
I've tested this a bit, and it seems that libgomp support is worse than I anticipated. In fact, with Gentoo gcc install it's not even able to find omp.h without explicit -I. I've therefore went ahead and switched -9999 to using libomp by default.
FYI OpenMP is now enabled by default: https://github.com/llvm-mirror/llvm/commit/5ebd7badfb495172b0e77ba594aa3c766f626b82
commit 570a1aa0e0ca2137f86350351eace21af78b18ad Author: Michał Górny <mgorny@gentoo.org> Date: Sat Dec 12 23:50:47 2015 sys-devel/llvm: Clean Python, enable libomp and BPF backend in 3.7 Backport some of the changes from -9999 as 3.7.0-r4. Remove multi-Python support which was working only partially because of lldb, also fixing byte-compilation of Python modules, #567550. Default to libomp instead of semi-broken libgomp support, #562990. Enable BPF backend by default, GitHub PR #450. Fixes: https://bugs.gentoo.org/show_bug.cgi?id=567550 Fixes: https://bugs.gentoo.org/show_bug.cgi?id=562990 Fixes: https://github.com/gentoo/gentoo/pull/450
Wonderful! It now works fine with just -fopenmp. Minor nit: I noticed that the -r4 ebuild still says to use -fopenmp=libomp in pkg_postinst(), that could be trimmed.
(In reply to Holger Hoffstätte from comment #11) > Wonderful! It now works fine with just -fopenmp. > Minor nit: I noticed that the -r4 ebuild still says to use -fopenmp=libomp > in pkg_postinst(), that could be trimmed. Yeah, I noticed that one as well after pushing it but decided it doesn't hurt. We still need to tell people to install libomp anyway.
