<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 23, 2015 at 3:16 PM, Jack Howarth <span dir="ltr"><<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Richard,<br>
Please try linux again with current openmp trunk and the<br>
proposed cmake overhaul changes from...<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10656&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=VLB239E11c50N5wXB1TePETr2hV1BOjlECQ0aomfImI&s=Dp2eyuthCDrPyn5I7xclqFI4BQEOUXJi-rozqZYdadA&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10656</a><br>
<br>
using the patch at...<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_file_data_yelxztueytythwycxwjx_PHID-2DFILE-2Dm5boinw4uugif7ky6tpq_D10656.diff&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=VLB239E11c50N5wXB1TePETr2hV1BOjlECQ0aomfImI&s=MugbFTG8R7yto6DDvwDMsXWwZRtM1B68xSa4ksZZUjo&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/file/data/yelxztueytythwycxwjx/PHID-FILE-m5boinw4uugif7ky6tpq/D10656.diff</a><br>
<br>applied.<br></blockquote><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Done. The CMP0040 is gone, and I still get a working libomp.so. However, some of the libomp-micro-tests checks don't pass:</div><div><br></div><div>libomp-test-touch fails because it sets LD_LIBRARY_PATH to include [...]/build/projects/openmp/runtime/src, rather than the correct path [...]/build/lib</div><div><br></div><div>libomp-test-instr fails with "<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__check-2Dinstruction-2Dset.pl&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=VLB239E11c50N5wXB1TePETr2hV1BOjlECQ0aomfImI&s=lz6rLWO3CW05jhlBDhv9Vm02qD4mKd3b-U0q-wAaPns&e=">check-instruction-set.pl</a>: (x) Only works on lin_32 and lin_mic platforms."</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"> Jack<br>
</font></span><div class=""><div class="h5"><br>
On Tue, Jun 23, 2015 at 6:10 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> On Thu, Jun 11, 2015 at 8:45 PM, Jack Howarth<br>
> <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>><br>
>> Richard,<br>
>> I do my local build using tarballs generated from current trunk<br>
>> svn pulls. The rough formula I use (after these are extracted) are...<br>
>><br>
>><br>
>> cd llvm-3.7.0.src<br>
>> mv ../cfe-3.7.0.src tools/clang<br>
>> mv ../compiler-rt-3.7.0.src projects/compiler-rt<br>
>> mv ../libcxx-3.7.0.src projects/libcxx<br>
>> mv ../openmp-3.7.0.src projects/openmp<br>
><br>
><br>
> You will probably need to explicit support for checking out openmp here to<br>
> llvm/projects/CMakeLists.txt, in order to get the "same as libcxx" behavior<br>
> that Chandler is requesting.<br>
><br>
>><br>
>> mv ../polly-3.7.0.src tools/polly<br>
>> mv ../clang-tools-extra-3.7.0.src tools/clang/tools/extra<br>
>> mkdir build<br>
>> cd build<br>
>> cmake -DLLVM_BUILD_32_BITS:BOOL=OFF -DLLVM_TARGETS_TO_BUILD=X86 \<br>
>> -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_BUILD_TYPE=Release<br>
>> -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386" \<br>
>> -DCMAKE_OSX_SYSROOT:STRING=/<br>
>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \<br>
>> -DLLVM_ENABLE_LIBCXX=ON -DLIBCXX_LIBCPPABI_VERSION=""<br>
>> -DENABLE_CLANG_OPENMP=ON ..<br>
>> make VERBOSE=1<br>
><br>
><br>
> As promised, I tried this out on a Linux machine. Here's what I did:<br>
><br>
> * check out all the pieces, including putting<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_svn_llvm-2Dproject_openmp_trunk_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=VLB239E11c50N5wXB1TePETr2hV1BOjlECQ0aomfImI&s=iBbqastSPvRwSh1h0Tg9bKpDECgS-oajT3Jg2L3R8YI&e=" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/openmp/trunk/</a> into llvm/projects/openmp<br>
> * run cmake without specifying any special flags (this should "just work")<br>
> * build<br>
> * run clang from build area and test<br>
><br>
> Here's what I got:<br>
><br>
> # From cmake:<br>
><br>
> CMake Warning (dev) at projects/openmp/runtime/src/CMakeLists.txt:26<br>
> (add_custom_command):<br>
> Policy CMP0040 is not set: The target in the TARGET signature of<br>
> add_custom_command() must exist. Run "cmake --help-policy CMP0040" for<br>
> policy details. Use the cmake_policy command to set the policy and<br>
> suppress this warning.<br>
><br>
> The target name "common" is unknown in this context.<br>
><br>
> It looks like the cmake build is not correctly configured here. I'm not sure<br>
> whether these custom commands are the right way to handle these header<br>
> files, but the TARGET should presumably be "libomp-common" or "libomp-mod",<br>
> not just "common" or "mod". I assume this will be fixed by the cmake build<br>
> system rework.<br>
><br>
> # From build:<br>
><br>
> *Lots* of warnings, but a successful build. These warnings should be fixed<br>
> (or, where appropriate, suppressed), but I don't personally think that needs<br>
> to be a prerequisite for changing the default value of -fopenmp=.<br>
><br>
> # From running Clang with -fopenmp=libomp:<br>
><br>
> Everything I tested works fine (the not-yet-installed library is not found,<br>
> but that seems like the right behaviour if we expect this library to live in<br>
> /usr/lib rather than in a compiler-specific library area). However, I<br>
> couldn't find a make target to run the libomp tests, and I couldn't find a<br>
> target to install the libomp runtime.<br>
><br>
>> This builds the libomp.dylib as a fat binary on x86_64 darwin (for<br>
>> both i386/x86_64 support).<br>
>> I always execute "perl -pi -e 's|libgomp|libomp|g' CMakeLists.txt" in<br>
>> tools/clang before the build to<br>
>> switch the -fopenmp default to libomp.<br>
>> Jack<br>
>><br>
>> On Thu, Jun 11, 2015 at 10:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > On Thu, Jun 11, 2015 at 7:26 PM, Jack Howarth<br>
>> > <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Thu, Jun 11, 2015 at 9:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> >> wrote:<br>
>> >> > On Thu, Jun 11, 2015 at 4:58 PM, Jack Howarth<br>
>> >> > <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Chandler,<br>
>> >> >> It has been over 10 days with no response (3 more than you<br>
>> >> >> used<br>
>> >> >> to justify reverting the libiomp5 default for -fopenmp). What<br>
>> >> >> blockers<br>
>> >> >> remain in current cfe/openmp svn which would prevent the default for<br>
>> >> >> -fopenmp from being switched over to libomp?<br>
>> >> ><br>
>> >> ><br>
>> >> > From my prior email these were the steps:<br>
>> >> ><br>
>> >> > "1) Reach the point where the openmp runtime library can be checked<br>
>> >> > out<br>
>> >> > into<br>
>> >> > a normal llvm / clang build tree (into projects/openmp, perhaps) and<br>
>> >> > it<br>
>> >> > integrates properly into the build and builds successfully on various<br>
>> >> > systems.<br>
>> >> > 2) Update the clang "getting started" documentation to suggest doing<br>
>> >> > this if<br>
>> >> > the user wants OpenMP support<br>
>> >> > (changehttp://<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_get-5Fstarted.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=VLB239E11c50N5wXB1TePETr2hV1BOjlECQ0aomfImI&s=B0jy6jFKovaqrzeKLGkd-wCkpKgbbCvwy_mIE_1fbBc&e=" rel="noreferrer" target="_blank">clang.llvm.org/get_started.html</a><br>
>> >> > to say what to check out and where -- no steps other than an 'svn co'<br>
>> >> > should<br>
>> >> > be necessary).<br>
>> >> > 3) Change the default for CLANG_DEFAULT_OPENMP_RUNTIME to libomp<br>
>> >> > (possibly<br>
>> >> > conditioned on a "is libomp part of this build?" test)."<br>
>> >> ><br>
>> >> > Step 2 has certainly not happened. Has step 1 happened?<br>
>> >><br>
>> >> I have been building current openmp in the llvm/projects/openmp<br>
>> >> location as a cmake<br>
>> >> build on x86_64-apple-darwin14 daily without issues. So step 1 is<br>
>> >> complete on darwin.<br>
>> ><br>
>> ><br>
>> > If you can let me know what I should check out where, I'll be happy to<br>
>> > test<br>
>> > it on Linux for you. (Should I check out<br>
>> > <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_svn_llvm-2Dproject_openmp_trunk_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=VLB239E11c50N5wXB1TePETr2hV1BOjlECQ0aomfImI&s=iBbqastSPvRwSh1h0Tg9bKpDECgS-oajT3Jg2L3R8YI&e=" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/openmp/trunk/</a> or just the runtime/<br>
>> > subdirectory there?)<br>
>> ><br>
>> > It looks like the openmp directory is not listed in llvm's<br>
>> > projects/CMakeLists.txt, so there may be some more integration work<br>
>> > required<br>
>> > for this to integrate properly into the llvm/clang build.<br>
>> ><br>
>> >> >> Jack<br>
>> >> >><br>
>> >> >> On Mon, Jun 1, 2015 at 7:34 AM, Jack Howarth<br>
>> >> >> <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >> >> > Chandler,<br>
>> >> >> > Now that openmp trunk is producing the desired renamed<br>
>> >> >> > libomp<br>
>> >> >> > shared library by default and a libgomp symlink to it for use by<br>
>> >> >> > -fopenmp=libgomp, do you have any remaining objections to<br>
>> >> >> > switching<br>
>> >> >> > CLANG_DEFAULT_OPENMP_RUNTIME from libgomp to libomp?<br>
>> >> >> > Jack<br>
>> >> >> > ps As the recent posting in cfe-commits indicates....<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150525/130067.html" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150525/130067.html</a><br>
>> >> >> ><br>
>> >> >> > the absence of complaints about the previous -fopenmp=libgomp<br>
>> >> >> > default<br>
>> >> >> > may be more due to misconceptions about the level of support for<br>
>> >> >> > OpenMP that provides rather than any real desire to use it in<br>
>> >> >> > place<br>
>> >> >> > of<br>
>> >> >> > the LLVM openmp (which is completely functional).<br>
>> >> >> _______________________________________________<br>
>> >> >> cfe-dev mailing list<br>
>> >> >> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> >> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>