Bataev, Alexey
2015-May-13 13:24 UTC
[LLVMdev] [Openmp-dev] OpenMP 3.1 Implementation Complete
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 ============Software Engineer Intel Compiler Team 13.05.2015 15:59, Jack Howarth пишет:> On Tue, May 12, 2015 at 3:58 PM, <andreybokhanko at gmail.com> wrote: >> 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 > >> Отправлено с iPad >> >>> 12 мая 2015 г., в 21:22, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): >>> >>> Andrey, >>> Any idea when the patch to enable openmp as the default for >>> -fopenmp will be posted to cfe-commits? >>> Jack >>> >>> On Fri, May 8, 2015 at 4:10 PM, Andrey Bokhanko >>> <andreybokhanko at gmail.com> wrote: >>>> No, just changing defaults -- subject to code reviewers approval. >>>> >>>> As I said before, I prefer to leave library naming to library pros. >>>> >>>> Andrey >>>> >>>> >>>> On Fri, May 8, 2015 at 7:21 PM, Jack Howarth >>>> <howarth.mailing.lists at gmail.com> wrote: >>>>> So you plan on switching and enabling the openmp library defaults as >>>>> well as changing the openmp library name at the same time? >>>>> Jack >>>>> >>>>> On Fri, May 8, 2015 at 12:04 PM, andreybokhanko >>>>> <andreybokhanko at gmail.com> wrote: >>>>>> It will come on next week. >>>>>> >>>>>> I'd like to give a chance to everyone to raise their objections first. >>>>>> >>>>>> Yours, >>>>>> Andrey >>>>>> >>>>>>> 8 мая 2015 г., в 18:30, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> On Fri, May 8, 2015 at 9:26 AM, Andrey Bokhanko >>>>>>> <andreybokhanko at gmail.com> wrote: >>>>>>>> On Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> wrote: >>>>>>>>> Congratulations! Would you like to add a blurb to the release notes >>>>>>>>> for the next release? >>>>>>>> Sure! Will do. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Andrey >>>>>>>> _______________________________________________ >>>>>>>> Openmp-dev mailing list >>>>>>>> Openmp-dev at dcs-maillist2.engr.illinois.edu >>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
Jack Howarth
2015-May-13 14:03 UTC
[LLVMdev] [Openmp-dev] OpenMP 3.1 Implementation Complete
On Wed, May 13, 2015 at 9:24 AM, Bataev, Alexey <a.bataev at hotmail.com> wrote:> 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> >> On Tue, May 12, 2015 at 3:58 PM, <andreybokhanko at gmail.com> wrote: >>> >>> 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 >> >>> Отправлено с iPad >>> >>>> 12 мая 2015 г., в 21:22, Jack Howarth <howarth.mailing.lists at gmail.com> >>>> написал(а): >>>> >>>> Andrey, >>>> Any idea when the patch to enable openmp as the default for >>>> -fopenmp will be posted to cfe-commits? >>>> Jack >>>> >>>> On Fri, May 8, 2015 at 4:10 PM, Andrey Bokhanko >>>> <andreybokhanko at gmail.com> wrote: >>>>> >>>>> No, just changing defaults -- subject to code reviewers approval. >>>>> >>>>> As I said before, I prefer to leave library naming to library pros. >>>>> >>>>> Andrey >>>>> >>>>> >>>>> On Fri, May 8, 2015 at 7:21 PM, Jack Howarth >>>>> <howarth.mailing.lists at gmail.com> wrote: >>>>>> >>>>>> So you plan on switching and enabling the openmp library defaults as >>>>>> well as changing the openmp library name at the same time? >>>>>> Jack >>>>>> >>>>>> On Fri, May 8, 2015 at 12:04 PM, andreybokhanko >>>>>> <andreybokhanko at gmail.com> wrote: >>>>>>> >>>>>>> It will come on next week. >>>>>>> >>>>>>> I'd like to give a chance to everyone to raise their objections >>>>>>> first. >>>>>>> >>>>>>> Yours, >>>>>>> Andrey >>>>>>> >>>>>>>> 8 мая 2015 г., в 18:30, Jack Howarth >>>>>>>> <howarth.mailing.lists at gmail.com> написал(а): >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> On Fri, May 8, 2015 at 9:26 AM, Andrey Bokhanko >>>>>>>> <andreybokhanko at gmail.com> wrote: >>>>>>>>> >>>>>>>>> On Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Congratulations! Would you like to add a blurb to the release >>>>>>>>>> notes >>>>>>>>>> for the next release? >>>>>>>>> >>>>>>>>> Sure! Will do. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Andrey >>>>>>>>> _______________________________________________ >>>>>>>>> Openmp-dev mailing list >>>>>>>>> Openmp-dev at dcs-maillist2.engr.illinois.edu >>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev > >
Jack Howarth
2015-May-13 14:42 UTC
[LLVMdev] [Openmp-dev] OpenMP 3.1 Implementation Complete
On Wed, May 13, 2015 at 10:03 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> On Wed, May 13, 2015 at 9:24 AM, Bataev, Alexey <a.bataev at hotmail.com> wrote: >> 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> 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 > >> >>> On Tue, May 12, 2015 at 3:58 PM, <andreybokhanko at gmail.com> wrote: >>>> >>>> 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 >>> >>>> Отправлено с iPad >>>> >>>>> 12 мая 2015 г., в 21:22, Jack Howarth <howarth.mailing.lists at gmail.com> >>>>> написал(а): >>>>> >>>>> Andrey, >>>>> Any idea when the patch to enable openmp as the default for >>>>> -fopenmp will be posted to cfe-commits? >>>>> Jack >>>>> >>>>> On Fri, May 8, 2015 at 4:10 PM, Andrey Bokhanko >>>>> <andreybokhanko at gmail.com> wrote: >>>>>> >>>>>> No, just changing defaults -- subject to code reviewers approval. >>>>>> >>>>>> As I said before, I prefer to leave library naming to library pros. >>>>>> >>>>>> Andrey >>>>>> >>>>>> >>>>>> On Fri, May 8, 2015 at 7:21 PM, Jack Howarth >>>>>> <howarth.mailing.lists at gmail.com> wrote: >>>>>>> >>>>>>> So you plan on switching and enabling the openmp library defaults as >>>>>>> well as changing the openmp library name at the same time? >>>>>>> Jack >>>>>>> >>>>>>> On Fri, May 8, 2015 at 12:04 PM, andreybokhanko >>>>>>> <andreybokhanko at gmail.com> wrote: >>>>>>>> >>>>>>>> It will come on next week. >>>>>>>> >>>>>>>> I'd like to give a chance to everyone to raise their objections >>>>>>>> first. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Andrey >>>>>>>> >>>>>>>>> 8 мая 2015 г., в 18:30, Jack Howarth >>>>>>>>> <howarth.mailing.lists at gmail.com> написал(а): >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> On Fri, May 8, 2015 at 9:26 AM, Andrey Bokhanko >>>>>>>>> <andreybokhanko at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> On Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Congratulations! Would you like to add a blurb to the release >>>>>>>>>>> notes >>>>>>>>>>> for the next release? >>>>>>>>>> >>>>>>>>>> Sure! Will do. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Andrey >>>>>>>>>> _______________________________________________ >>>>>>>>>> Openmp-dev mailing list >>>>>>>>>> Openmp-dev at dcs-maillist2.engr.illinois.edu >>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev >> >>