<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 11, 2015 at 8:45 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"><span class="">Richard,<br>
I do my local build using tarballs generated from current trunk<br>
svn pulls. </span>The rough formula I use (after these are extracted) are...</blockquote><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="">
<br>
</span>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></blockquote><div><br></div><div>You will probably need to explicit support for checking out openmp here to llvm/projects/CMakeLists.txt, in order to get the "same as libcxx" behavior that Chandler is requesting.</div><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">
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></blockquote><div><br></div><div>As promised, I tried this out on a Linux machine. Here's what I did:</div><div><br></div><div> * check out all the pieces, including putting <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=XrRkTVXWeS5Q6zIAEBCXRpAXwh0kMSlzHHTaAnQv4Wk&s=UZfDQi4L0NiySOqU0jNWD0Ov-uO25tBgGua0BsRNR_Y&e=" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/openmp/trunk/</a> into llvm/projects/openmp</div><div> * run cmake without specifying any special flags (this should "just work")</div><div> * build</div><div> * run clang from build area and test</div><div><br></div><div>Here's what I got:</div><div><div><br></div><div># From cmake:</div><div><br></div><div>CMake Warning (dev) at projects/openmp/runtime/src/CMakeLists.txt:26 (add_custom_command):</div><div> Policy CMP0040 is not set: The target in the TARGET signature of</div><div> add_custom_command() must exist. Run "cmake --help-policy CMP0040" for</div><div> policy details. Use the cmake_policy command to set the policy and</div><div> suppress this warning.</div><div><br></div><div> The target name "common" is unknown in this context.</div></div><div><br></div><div>It looks like the cmake build is not correctly configured here. I'm not sure whether these custom commands are the right way to handle these header files, but the TARGET should presumably be "libomp-common" or "libomp-mod", not just "common" or "mod". I assume this will be fixed by the cmake build system rework.</div><div><br></div><div># From build:</div><div><br></div><div>*Lots* of warnings, but a successful build. These warnings should be fixed (or, where appropriate, suppressed), but I don't personally think that needs to be a prerequisite for changing the default value of -fopenmp=.</div><div><br></div><div># From running Clang with -fopenmp=libomp:</div><div><br></div><div>Everything I tested works fine (the not-yet-installed library is not found, but that seems like the right behaviour if we expect this library to live in /usr/lib rather than in a compiler-specific library area). However, I couldn't find a make target to run the libomp tests, and I couldn't find a target to install the libomp runtime.</div><div><br></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">
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>
<span class=""><font color="#888888"> Jack<br>
</font></span><div class=""><div class="h5"><br>
On Thu, Jun 11, 2015 at 10:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> 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 used<br>
>> >> to justify reverting the libiomp5 default for -fopenmp). What 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 out<br>
>> > into<br>
>> > a normal llvm / clang build tree (into projects/openmp, perhaps) and 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=XrRkTVXWeS5Q6zIAEBCXRpAXwh0kMSlzHHTaAnQv4Wk&s=TwIYZYmUmNYQDkNN4tjQzwNC1OUf9Z4T1yTDxe7ACXs&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 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=XrRkTVXWeS5Q6zIAEBCXRpAXwh0kMSlzHHTaAnQv4Wk&s=UZfDQi4L0NiySOqU0jNWD0Ov-uO25tBgGua0BsRNR_Y&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 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 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 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>
>> >> > <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 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 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>
</div></div></blockquote></div><br></div></div>