Bill,
I have the openmp support in llvm 3.5svn now built on 10.7 using Xcode
4.6.3 and 10.8/10.9 using 5.1.1. The 10.7 build required the hack…
perl -pi -e 's|list\(APPEND SANITIZER_COMMON_SUPPORTED_DARWIN_OS
iossim\)||g' projects/compiler-rt/CMakeLists.txt
to suppress building libclang_rt.asan_iossim_dynamic.dylib. The compiler-rt
build now expects the iPhoneSimulator7.0.0.sdk but Xcode 4.6.3 only has the
/iPhoneSimulator6.1.sdk. I tried tweaking that back to 6.1 but the build of
llibclang_rt.asan_iossim_dynamic.dylib. wants link to a copy of
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/libc++.dylib
as a x86_64 binary but it only exists as i386.
Jack
ps The previous report of omp_workshare2.c example failing to compile can
be ignored as that was a stray character in my copy.
On Sun, May 18, 2014 at 3:31 PM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:
> It appears that the failure in the openmp build is due to a race
> condition as if I use…
>
> make -j1 compiler=clang
>
> the failure in building openmp on my 10.8 box disappears.
>
>
>
> On Sun, May 18, 2014 at 1:36 PM, Jack Howarth <
> howarth.mailing.lists at gmail.com> wrote:
>
>> Bill,
>> Are there any plans to integrate the new openmp support into the
>> llvm/clang 3.5 build process? I have been able to build the current
>> llvm/clang/compiler-rt/openmp svn on Mac OS X 10.9 out of tree with…
>>
>> pushd projects/openmp/runtime
>> make compiler=clang
>> popd
>>
>> and then
>>
>> OPENMP_DIR=`ls projects/openmp/runtime/tmp | grep dyn`
>> pushd projects/openmp/runtime/tmp/$OPENMP_DIR
>> install -m 755 libiomp5.dylib %i/opt/llvm-%v/lib/libgomp.dylib
>> install -m 644 *.h %i/opt/llvm-%v/lib/clang/%v/include
>> popd
>>
>> in our fink llvm packaging.
>> It would be nice to see the cmake build machinery updated to
>> automatically build and install openmp if its sources are placed in the
>> projects subdirectory of the llvm-3.5.0 source directory. Even if there
>> isn't cmake build integration, but assuming an openmp 3.5.0 tar
ball will
>> be released for llvm/clang 3.5.0, the flag for openmp support needs to
be
>> synced to the library name generated in openmp. Currently, the clang
flag
>> -fopenmp flag emits -lgomp whereas the openmp svn currently produces a
>> libiomp5.dylib instead. Also, the clang compiler currently has to be
passed
>> an explicitly library path to the location of the libgomp.dylib with
-L.
>> While the openmp headers can be found by clang when placed in
clang's
>> include directory, the libgomp.dylib shared lib isn't found when
placed in
>> any of the llvm/clang internal lib directories. If the file is going to
be
>> renamed as libgomp.dylib, it should be buried in the llvm/clang
directories
>> so that it doesn't collide with the FSF one. I can see the rational
of
>> using libgomp.dylib, so that configure and cmake detection of openmp is
>> triggered, but in the long run it probably should be using a different
>> shared library name.
>> Jack
>> ps I found on 10.9, that current llvm/clang/openmp can compile and run
>> all of the example code at
>> https://computing.llnl.gov/tutorials/openMP/exercise.html to build
>> except for
omp_workshare2.c<https://computing.llnl.gov/tutorials/openMP/samples/C/omp_workshare2.c>.
>> FYI, there appears to be an issue with building current openmp on 10.8
>> using the same approach. The openmp code appears to compile but the
build
>> fails with…
>>
>> make[1]: Leaving directory
>>
'/sw/src/fink.build/llvm35-3.5.0-0/llvm-3.5.0/projects/openmp/runtime/tmp/mac_32e-rtl_5_nor_dyn.12.rel.40.c0.t0-prrg4'
>>
>>
-------------------------------------------------------------------------------
>> Finished : 2014-05-17 01:49:01 UTC
>> Elapsed : 00:00:02
>> Result : --- Failure ---
>>
>>
-------------------------------------------------------------------------------
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140518/b101e780/attachment.html>
Hi Jack, I didn’t have any specific plans for OpenMP in the release. If you’d be willing to test and build for OpenMP, then we could release it. :-) -bw On May 18, 2014, at 4:46 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> Bill, > I have the openmp support in llvm 3.5svn now built on 10.7 using Xcode 4.6.3 and 10.8/10.9 using 5.1.1. The 10.7 build required the hack… > > perl -pi -e 's|list\(APPEND SANITIZER_COMMON_SUPPORTED_DARWIN_OS iossim\)||g' projects/compiler-rt/CMakeLists.txt > > to suppress building libclang_rt.asan_iossim_dynamic.dylib. The compiler-rt build now expects the iPhoneSimulator7.0.0.sdk but Xcode 4.6.3 only has the /iPhoneSimulator6.1.sdk. I tried tweaking that back to 6.1 but the build of llibclang_rt.asan_iossim_dynamic.dylib. wants link to a copy of /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/libc++.dylib as a x86_64 binary but it only exists as i386. > Jack > ps The previous report of omp_workshare2.c example failing to compile can be ignored as that was a stray character in my copy. > > On Sun, May 18, 2014 at 3:31 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > It appears that the failure in the openmp build is due to a race condition as if I use… > > make -j1 compiler=clang > > the failure in building openmp on my 10.8 box disappears. > > > > On Sun, May 18, 2014 at 1:36 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > Bill, > Are there any plans to integrate the new openmp support into the llvm/clang 3.5 build process? I have been able to build the current llvm/clang/compiler-rt/openmp svn on Mac OS X 10.9 out of tree with… > > pushd projects/openmp/runtime > make compiler=clang > popd > > and then > > OPENMP_DIR=`ls projects/openmp/runtime/tmp | grep dyn` > pushd projects/openmp/runtime/tmp/$OPENMP_DIR > install -m 755 libiomp5.dylib %i/opt/llvm-%v/lib/libgomp.dylib > install -m 644 *.h %i/opt/llvm-%v/lib/clang/%v/include > popd > > in our fink llvm packaging. > It would be nice to see the cmake build machinery updated to automatically build and install openmp if its sources are placed in the projects subdirectory of the llvm-3.5.0 source directory. Even if there isn't cmake build integration, but assuming an openmp 3.5.0 tar ball will be released for llvm/clang 3.5.0, the flag for openmp support needs to be synced to the library name generated in openmp. Currently, the clang flag -fopenmp flag emits -lgomp whereas the openmp svn currently produces a libiomp5.dylib instead. Also, the clang compiler currently has to be passed an explicitly library path to the location of the libgomp.dylib with -L. While the openmp headers can be found by clang when placed in clang's include directory, the libgomp.dylib shared lib isn't found when placed in any of the llvm/clang internal lib directories. If the file is going to be renamed as libgomp.dylib, it should be buried in the llvm/clang directories so that it doesn't collide with the FSF one. I can see the rational of using libgomp.dylib, so that configure and cmake detection of openmp is triggered, but in the long run it probably should be using a different shared library name. > Jack > ps I found on 10.9, that current llvm/clang/openmp can compile and run all of the example code at https://computing.llnl.gov/tutorials/openMP/exercise.html to build except for omp_workshare2.c. FYI, there appears to be an issue with building current openmp on 10.8 using the same approach. The openmp code appears to compile but the build fails with… > > make[1]: Leaving directory '/sw/src/fink.build/llvm35-3.5.0-0/llvm-3.5.0/projects/openmp/runtime/tmp/mac_32e-rtl_5_nor_dyn.12.rel.40.c0.t0-prrg4' > ------------------------------------------------------------------------------- > Finished : 2014-05-17 01:49:01 UTC > Elapsed : 00:00:02 > Result : --- Failure --- > ------------------------------------------------------------------------------- > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140521/8d4848a9/attachment.html>
Sebastian Dreßler
2014-May-22 06:42 UTC
[LLVMdev] Clang 3.5 Release Pre-Pre-Pre-Announcement
Hi, Having OpenMP together with clang would be awesome! If there is additional need for testing, I'd be happy to volunteer for that. Cheers, Sebastian 2014-05-22 7:26 GMT+02:00 Bill Wendling <isanbard at gmail.com>:> Hi Jack, > > I didn’t have any specific plans for OpenMP in the release. If you’d be > willing to test and build for OpenMP, then we could release it. :-) > > -bw > > On May 18, 2014, at 4:46 PM, Jack Howarth <howarth.mailing.lists at gmail.com> > wrote: > > Bill, > I have the openmp support in llvm 3.5svn now built on 10.7 using > Xcode 4.6.3 and 10.8/10.9 using 5.1.1. The 10.7 build required the hack… > > perl -pi -e 's|list\(APPEND SANITIZER_COMMON_SUPPORTED_DARWIN_OS > iossim\)||g' projects/compiler-rt/CMakeLists.txt > > to suppress building libclang_rt.asan_iossim_dynamic.dylib. The > compiler-rt build now expects the iPhoneSimulator7.0.0.sdk but Xcode 4.6.3 > only has the /iPhoneSimulator6.1.sdk. I tried tweaking that back to 6.1 but > the build of llibclang_rt.asan_iossim_dynamic.dylib. wants link to a copy > of > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/libc++.dylib > as a x86_64 binary but it only exists as i386. > Jack > ps The previous report of omp_workshare2.c example failing to compile can > be ignored as that was a stray character in my copy. > > On Sun, May 18, 2014 at 3:31 PM, Jack Howarth < > howarth.mailing.lists at gmail.com> wrote: > >> It appears that the failure in the openmp build is due to a race >> condition as if I use… >> >> make -j1 compiler=clang >> >> the failure in building openmp on my 10.8 box disappears. >> >> >> >> On Sun, May 18, 2014 at 1:36 PM, Jack Howarth < >> howarth.mailing.lists at gmail.com> wrote: >> >>> Bill, >>> Are there any plans to integrate the new openmp support into the >>> llvm/clang 3.5 build process? I have been able to build the current >>> llvm/clang/compiler-rt/openmp svn on Mac OS X 10.9 out of tree with… >>> >>> pushd projects/openmp/runtime >>> make compiler=clang >>> popd >>> >>> and then >>> >>> OPENMP_DIR=`ls projects/openmp/runtime/tmp | grep dyn` >>> pushd projects/openmp/runtime/tmp/$OPENMP_DIR >>> install -m 755 libiomp5.dylib %i/opt/llvm-%v/lib/libgomp.dylib >>> install -m 644 *.h %i/opt/llvm-%v/lib/clang/%v/include >>> popd >>> >>> in our fink llvm packaging. >>> It would be nice to see the cmake build machinery updated to >>> automatically build and install openmp if its sources are placed in the >>> projects subdirectory of the llvm-3.5.0 source directory. Even if there >>> isn't cmake build integration, but assuming an openmp 3.5.0 tar ball will >>> be released for llvm/clang 3.5.0, the flag for openmp support needs to be >>> synced to the library name generated in openmp. Currently, the clang flag >>> -fopenmp flag emits -lgomp whereas the openmp svn currently produces a >>> libiomp5.dylib instead. Also, the clang compiler currently has to be passed >>> an explicitly library path to the location of the libgomp.dylib with -L. >>> While the openmp headers can be found by clang when placed in clang's >>> include directory, the libgomp.dylib shared lib isn't found when placed in >>> any of the llvm/clang internal lib directories. If the file is going to be >>> renamed as libgomp.dylib, it should be buried in the llvm/clang directories >>> so that it doesn't collide with the FSF one. I can see the rational of >>> using libgomp.dylib, so that configure and cmake detection of openmp is >>> triggered, but in the long run it probably should be using a different >>> shared library name. >>> Jack >>> ps I found on 10.9, that current llvm/clang/openmp can compile and run >>> all of the example code at >>> https://computing.llnl.gov/tutorials/openMP/exercise.html to build >>> except for omp_workshare2.c<https://computing.llnl.gov/tutorials/openMP/samples/C/omp_workshare2.c>. >>> FYI, there appears to be an issue with building current openmp on 10.8 >>> using the same approach. The openmp code appears to compile but the build >>> fails with… >>> >>> make[1]: Leaving directory >>> '/sw/src/fink.build/llvm35-3.5.0-0/llvm-3.5.0/projects/openmp/runtime/tmp/mac_32e-rtl_5_nor_dyn.12.rel.40.c0.t0-prrg4' >>> >>> ------------------------------------------------------------------------------- >>> Finished : 2014-05-17 01:49:01 UTC >>> Elapsed : 00:00:02 >>> Result : --- Failure --- >>> >>> ------------------------------------------------------------------------------- >>> >>> >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140522/18162377/attachment.html>
Bill,
Actually,the solution we are going to use in fink is to apply a diff
of current clang-omp (which is based on stock clang 3.4) from commit
f9e2fd7640f8fc06ebe1ef2f065c6158f6b4b6ef against stock clang 3.4 to our
llvm34-3.4.1 package in fink. This is built against a openmp r208472 pull
from trunk at llvm.org. The resulting clang 3.4.1 compiler defaults
-fopenmp to -liomp5 (as that switch over as already occurred in clang-omp
github). It passes all of the OpenMP3.1_Validation except for a known
failure (https://github.com/clang-omp/clang/issues/34) as well as all
of taskbench-1.0-20110715 on x86_64-apple-darwin11/12/13. It should appear
in the fink packaging set after we sort out some unrelated packaging issues.
Jack
On Thu, May 22, 2014 at 1:26 AM, Bill Wendling <isanbard at gmail.com>
wrote:
> Hi Jack,
>
> I didn’t have any specific plans for OpenMP in the release. If you’d be
> willing to test and build for OpenMP, then we could release it. :-)
>
> -bw
>
> On May 18, 2014, at 4:46 PM, Jack Howarth <howarth.mailing.lists at
gmail.com>
> wrote:
>
> Bill,
> I have the openmp support in llvm 3.5svn now built on 10.7 using
> Xcode 4.6.3 and 10.8/10.9 using 5.1.1. The 10.7 build required the hack…
>
> perl -pi -e 's|list\(APPEND SANITIZER_COMMON_SUPPORTED_DARWIN_OS
> iossim\)||g' projects/compiler-rt/CMakeLists.txt
>
> to suppress building libclang_rt.asan_iossim_dynamic.dylib. The
> compiler-rt build now expects the iPhoneSimulator7.0.0.sdk but Xcode 4.6.3
> only has the /iPhoneSimulator6.1.sdk. I tried tweaking that back to 6.1 but
> the build of llibclang_rt.asan_iossim_dynamic.dylib. wants link to a copy
> of
>
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/libc++.dylib
> as a x86_64 binary but it only exists as i386.
> Jack
> ps The previous report of omp_workshare2.c example failing to compile can
> be ignored as that was a stray character in my copy.
>
> On Sun, May 18, 2014 at 3:31 PM, Jack Howarth <
> howarth.mailing.lists at gmail.com> wrote:
>
>> It appears that the failure in the openmp build is due to a race
>> condition as if I use…
>>
>> make -j1 compiler=clang
>>
>> the failure in building openmp on my 10.8 box disappears.
>>
>>
>>
>> On Sun, May 18, 2014 at 1:36 PM, Jack Howarth <
>> howarth.mailing.lists at gmail.com> wrote:
>>
>>> Bill,
>>> Are there any plans to integrate the new openmp support into
the
>>> llvm/clang 3.5 build process? I have been able to build the current
>>> llvm/clang/compiler-rt/openmp svn on Mac OS X 10.9 out of tree
with…
>>>
>>> pushd projects/openmp/runtime
>>> make compiler=clang
>>> popd
>>>
>>> and then
>>>
>>> OPENMP_DIR=`ls projects/openmp/runtime/tmp | grep dyn`
>>> pushd projects/openmp/runtime/tmp/$OPENMP_DIR
>>> install -m 755 libiomp5.dylib
%i/opt/llvm-%v/lib/libgomp.dylib
>>> install -m 644 *.h %i/opt/llvm-%v/lib/clang/%v/include
>>> popd
>>>
>>> in our fink llvm packaging.
>>> It would be nice to see the cmake build machinery updated to
>>> automatically build and install openmp if its sources are placed in
the
>>> projects subdirectory of the llvm-3.5.0 source directory. Even if
there
>>> isn't cmake build integration, but assuming an openmp 3.5.0 tar
ball will
>>> be released for llvm/clang 3.5.0, the flag for openmp support needs
to be
>>> synced to the library name generated in openmp. Currently, the
clang flag
>>> -fopenmp flag emits -lgomp whereas the openmp svn currently
produces a
>>> libiomp5.dylib instead. Also, the clang compiler currently has to
be passed
>>> an explicitly library path to the location of the libgomp.dylib
with -L.
>>> While the openmp headers can be found by clang when placed in
clang's
>>> include directory, the libgomp.dylib shared lib isn't found
when placed in
>>> any of the llvm/clang internal lib directories. If the file is
going to be
>>> renamed as libgomp.dylib, it should be buried in the llvm/clang
directories
>>> so that it doesn't collide with the FSF one. I can see the
rational of
>>> using libgomp.dylib, so that configure and cmake detection of
openmp is
>>> triggered, but in the long run it probably should be using a
different
>>> shared library name.
>>> Jack
>>> ps I found on 10.9, that current llvm/clang/openmp can compile and
run
>>> all of the example code at
>>> https://computing.llnl.gov/tutorials/openMP/exercise.html to build
>>> except for
omp_workshare2.c<https://computing.llnl.gov/tutorials/openMP/samples/C/omp_workshare2.c>.
>>> FYI, there appears to be an issue with building current openmp on
10.8
>>> using the same approach. The openmp code appears to compile but the
build
>>> fails with…
>>>
>>> make[1]: Leaving directory
>>>
'/sw/src/fink.build/llvm35-3.5.0-0/llvm-3.5.0/projects/openmp/runtime/tmp/mac_32e-rtl_5_nor_dyn.12.rel.40.c0.t0-prrg4'
>>>
>>>
-------------------------------------------------------------------------------
>>> Finished : 2014-05-17 01:49:01 UTC
>>> Elapsed : 00:00:02
>>> Result : --- Failure ---
>>>
>>>
-------------------------------------------------------------------------------
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140522/677c24f8/attachment.html>