llvm dev - May 2015 - [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp

Chandler,

Thanks for the reply -- I always included you in libiomp supporters camp;
it is good to see I wasn't mistaken! ;-)

On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at
google.com>
wrote:
> Is there no way to support libgomp here as well? I don't say this to
hold
> up changing the defaults in any way, just curious. =]
>
No, sorry. libgomp doesn't support Intel API and clang generates Intel API
calls only -- as simple as that. Someday someone may implement generation
of GNU API calls as well, but this is a separate big task that, IMHO,
doesn't serve any real purpose -- and potentially introduces nasty
GPL-related legal issues.

There is an option to choose what library clang links
(-fopenmp={libiomp|libgomp}), though.

> I totally agree, I think things are way better now. I generally support
> the direction. I think there are a few things I'd suggest we do as part
of
> the process, but I think these are really small and just about
"how" we
> switch.
>
> 1) I completely agree with the comments some others have made about us
> needing to make it clear that this isn't some Intel-only thing, its the
> LLVM OpenMP runtime. Some suggestions that I think would make sense to help
> here:
> - I agree with finding some non-Intel folks to add as explicit code
> owners. I don't know who has been sufficiently involved, but if Hal
makes
> sense, awesome.
>
This really belongs to a separate thread (
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html); see my
answer there in a couple of minutes.

> - Clearly updating the readme and such would be appropriate.
> - I suspect we should change the name of the installed library.
'libiomp'
> is pretty clearly the Intel library. We could continue in the grand
> tradition of LLVM naming conventions and use 'libllomp'? Of course,
we
> should install symlinks under the name 'libiomp' if needed for
existing
> users to not be broken.
> - Any other changes?
>
Adding openmp-dev list (in retrospect, should have been done at the very
start...), Jim Cownie and Andrey Churbanov.

> 2) I think we need to update the instructions for checking out LLVM and
> all the tools to include checking out the openmp project. I'm planning
to
> try it out in a bit.
>
Cool! Thank you!

> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
Speaking of which, have you checked the performance of some of the
basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
This is very tricky for me -- I'm employed by a CPU vendor (Intel), and we
have very strict rules and long processes for publishing benchmark results.
I simply can't run a benchmark and say: "hey! clang has this number and
gcc
has that number".

The only thing I can share is that we do tested SPEC OMP2012 (
https://www.spec.org/omp2012/), which is the industry standard for OMP
benchmarks, on a non-server class Darwin machine, and the results are quite
good and comparable with other compilers.

Speaking on Phoronix, two benchmarks where clang always lose due to lack of
OpenMP are "John the Ripper" (
http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3)
and ImageMagick -- though latter is not included in most recent "clang vs
gcc" comparison.

Is there a generous soul (not employed by a CPU vendor :-)) willing to run
"John the Ripper" with "clang -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
-lm -O3" and compare results with "clang -O3"?

Also, Jack Howarth did testing with some other benchmarks, and it is nice
to see that clang + libiomp compare quite well (to say it mildly ;-)) with
gcc + libgomp!

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/30c3c3cc/attachment.html>

On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at
gmail.com>
wrote:
> Chandler,
>
> Thanks for the reply -- I always included you in libiomp supporters camp;
> it is good to see I wasn't mistaken! ;-)
>
> On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
>> Is there no way to support libgomp here as well? I don't say this
to hold
>> up changing the defaults in any way, just curious. =]
>>
>
> No, sorry. libgomp doesn't support Intel API and clang generates Intel
API
> calls only -- as simple as that. Someday someone may implement generation
> of GNU API calls as well, but this is a separate big task that, IMHO,
> doesn't serve any real purpose -- and potentially introduces nasty
> GPL-related legal issues.
>
> There is an option to choose what library clang links
> (-fopenmp={libiomp|libgomp}), though.
>
>
>> I totally agree, I think things are way better now. I generally support
>> the direction. I think there are a few things I'd suggest we do as
part of
>> the process, but I think these are really small and just about
"how" we
>> switch.
>>
>> 1) I completely agree with the comments some others have made about us
>> needing to make it clear that this isn't some Intel-only thing, its
the
>> LLVM OpenMP runtime. Some suggestions that I think would make sense to
help
>> here:
>> - I agree with finding some non-Intel folks to add as explicit code
>> owners. I don't know who has been sufficiently involved, but if Hal
makes
>> sense, awesome.
>>
>
> This really belongs to a separate thread (
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html); see
> my answer there in a couple of minutes.
>
>
>> - Clearly updating the readme and such would be appropriate.
>> - I suspect we should change the name of the installed library.
'libiomp'
>> is pretty clearly the Intel library. We could continue in the grand
>> tradition of LLVM naming conventions and use 'libllomp'? Of
course, we
>> should install symlinks under the name 'libiomp' if needed for
existing
>> users to not be broken.
>> - Any other changes?
>>
>
> Adding openmp-dev list (in retrospect, should have been done at the very
> start...), Jim Cownie and Andrey Churbanov.
>
>
>> 2) I think we need to update the instructions for checking out LLVM and
>> all the tools to include checking out the openmp project. I'm
planning to
>> try it out in a bit.
>>
>
> Cool! Thank you!
>
>
>> 3) It would be nice to get at least one boring benchmark into the
>> test-suite that uses OpenMP just so there's more coverage that the
basic
>> stuff all works. In particular, if we could get the benchmark that
Phoronix
>> and others keep pointing at, that'd be nice.
>>
>
> Speaking of which, have you checked the performance of some of the basic
>> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs
GCC
>> there? I'd be interested to see the numbers.
>>
>
> This is very tricky for me -- I'm employed by a CPU vendor (Intel), and
we
> have very strict rules and long processes for publishing benchmark results.
> I simply can't run a benchmark and say: "hey! clang has this
number and gcc
> has that number".
>
> The only thing I can share is that we do tested SPEC OMP2012 (
> https://www.spec.org/omp2012/), which is the industry standard for OMP
> benchmarks, on a non-server class Darwin machine, and the results are quite
> good and comparable with other compilers.
>
> Speaking on Phoronix, two benchmarks where clang always lose due to lack
> of OpenMP are "John the Ripper" (
>
http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3)
> and ImageMagick -- though latter is not included in most recent "clang
vs
> gcc" comparison.
>
> Is there a generous soul (not employed by a CPU vendor :-)) willing to run
> "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
> -lm -O3" and compare results with "clang -O3"?
>
Attached are preliminary benchmarking of John the Ripper 1.8.0 for clang
3.7svn with the two outstanding OPENMP patches applied and for gcc 5.1.0.
The attached john_the_ripper_clang-3.7.log and  john_the_ripper_gcc-5.1.log
files contain the benchmarks at -O2 and -O3 for each compiler. As before,
the runs are from x86_64-apple-darwin14 using a early 2008 MacPro with dual
2.8GHz quad-core Xeon processors and 10 Gb of memory.

> Also, Jack Howarth did testing with some other benchmarks, and it is nice
> to see that clang + libiomp compare quite well (to say it mildly ;-)) with
> gcc + libgomp!
>
> Andrey
>
>
> _______________________________________________
> 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/20150501/cec4bee7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: john_the_ripper_clang-3.7.log
Type: application/octet-stream
Size: 2416 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/cec4bee7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: john_the_ripper_gcc-5.1.log
Type: application/octet-stream
Size: 2256 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/cec4bee7/attachment-0001.obj>

On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at
gmail.com>
wrote:
> Chandler,
>
> Thanks for the reply -- I always included you in libiomp supporters camp;
> it is good to see I wasn't mistaken! ;-)
>
> On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
>> Is there no way to support libgomp here as well? I don't say this
to hold
>> up changing the defaults in any way, just curious. =]
>>
>
> No, sorry. libgomp doesn't support Intel API and clang generates Intel
API
> calls only -- as simple as that. Someday someone may implement generation
> of GNU API calls as well, but this is a separate big task that, IMHO,
> doesn't serve any real purpose -- and potentially introduces nasty
> GPL-related legal issues.
>
> There is an option to choose what library clang links
> (-fopenmp={libiomp|libgomp}), though.
>
>
>> I totally agree, I think things are way better now. I generally support
>> the direction. I think there are a few things I'd suggest we do as
part of
>> the process, but I think these are really small and just about
"how" we
>> switch.
>>
>> 1) I completely agree with the comments some others have made about us
>> needing to make it clear that this isn't some Intel-only thing, its
the
>> LLVM OpenMP runtime. Some suggestions that I think would make sense to
help
>> here:
>> - I agree with finding some non-Intel folks to add as explicit code
>> owners. I don't know who has been sufficiently involved, but if Hal
makes
>> sense, awesome.
>>
>
> This really belongs to a separate thread (
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html); see
> my answer there in a couple of minutes.
>
>
>> - Clearly updating the readme and such would be appropriate.
>> - I suspect we should change the name of the installed library.
'libiomp'
>> is pretty clearly the Intel library. We could continue in the grand
>> tradition of LLVM naming conventions and use 'libllomp'? Of
course, we
>> should install symlinks under the name 'libiomp' if needed for
existing
>> users to not be broken.
>> - Any other changes?
>>
>
> Adding openmp-dev list (in retrospect, should have been done at the very
> start...), Jim Cownie and Andrey Churbanov.
>
>
>> 2) I think we need to update the instructions for checking out LLVM and
>> all the tools to include checking out the openmp project. I'm
planning to
>> try it out in a bit.
>>
>
> Cool! Thank you!
>
>
>> 3) It would be nice to get at least one boring benchmark into the
>> test-suite that uses OpenMP just so there's more coverage that the
basic
>> stuff all works. In particular, if we could get the benchmark that
Phoronix
>> and others keep pointing at, that'd be nice.
>>
>
> Speaking of which, have you checked the performance of some of the basic
>> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs
GCC
>> there? I'd be interested to see the numbers.
>>
>
> This is very tricky for me -- I'm employed by a CPU vendor (Intel), and
we
> have very strict rules and long processes for publishing benchmark results.
> I simply can't run a benchmark and say: "hey! clang has this
number and gcc
> has that number".
>
> The only thing I can share is that we do tested SPEC OMP2012 (
> https://www.spec.org/omp2012/), which is the industry standard for OMP
> benchmarks, on a non-server class Darwin machine, and the results are quite
> good and comparable with other compilers.
>
> Speaking on Phoronix, two benchmarks where clang always lose due to lack
> of OpenMP are "John the Ripper" (
>
http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3)
> and ImageMagick -- though latter is not included in most recent "clang
vs
> gcc" comparison.
>
Unfortunately, the current llvm 3.7svn and available OPENMP patches don't
allow for imageMagick-6.8.2 to compile. The build fails on the compiler
error...

magick/attribute.c:331:12: error: loop iteration variable in the associated
loop of 'omp parallel for' directive may not be threadprivate or thread
local, predetermined as
      private
      for (i=0; i < (ssize_t) image->colors; i++)
           ^
magick/attribute.c:325:9: note: loop iteration variable is predetermined as
linear
        i;
        ^
magick/attribute.c:978:12: error: loop iteration variable in the associated
loop of 'omp parallel for' directive may not be threadprivate or thread
local, predetermined as
      private
      for (i=0; i < (ssize_t) image->colors; i++)
           ^
magick/attribute.c:972:9: note: loop iteration variable is predetermined as
linear
        i;
        ^
2 errors generated.

I get the same error when I try to build the latest ImageMagick 6.9.1-2
sources with clang 3.7svn using -fopenmp=libiomp5 -Xclang -fopenmp=libiomp5.

> Is there a generous soul (not employed by a CPU vendor :-)) willing to run
> "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
> -lm -O3" and compare results with "clang -O3"?
>
> Also, Jack Howarth did testing with some other benchmarks, and it is nice
> to see that clang + libiomp compare quite well (to say it mildly ;-)) with
> gcc + libgomp!
>
> Andrey
>
>
> _______________________________________________
> 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/20150501/4fabdda1/attachment.html>

Jack,

Thank you for measuring this!

If I interpret results correctly (higher numbers = better
performance), clang + libiomp combo produces faster (sometimes
significantly faster) code in practically every case!

Andrey


On Fri, May 1, 2015 at 3:26 PM, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
>
>
> On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at
gmail.com>
> wrote:
>>
>> Chandler,
>>
>> Thanks for the reply -- I always included you in libiomp supporters
camp;
>> it is good to see I wasn't mistaken! ;-)
>>
>> On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at
google.com>
>> wrote:
>>>
>>> Is there no way to support libgomp here as well? I don't say
this to hold
>>> up changing the defaults in any way, just curious. =]
>>
>>
>> No, sorry. libgomp doesn't support Intel API and clang generates
Intel API
>> calls only -- as simple as that. Someday someone may implement
generation of
>> GNU API calls as well, but this is a separate big task that, IMHO,
doesn't
>> serve any real purpose -- and potentially introduces nasty GPL-related
legal
>> issues.
>>
>> There is an option to choose what library clang links
>> (-fopenmp={libiomp|libgomp}), though.
>>
>>>
>>> I totally agree, I think things are way better now. I generally
support
>>> the direction. I think there are a few things I'd suggest we do
as part of
>>> the process, but I think these are really small and just about
"how" we
>>> switch.
>>>
>>> 1) I completely agree with the comments some others have made about
us
>>> needing to make it clear that this isn't some Intel-only thing,
its the LLVM
>>> OpenMP runtime. Some suggestions that I think would make sense to
help here:
>>> - I agree with finding some non-Intel folks to add as explicit code
>>> owners. I don't know who has been sufficiently involved, but if
Hal makes
>>> sense, awesome.
>>
>>
>> This really belongs to a separate thread
>> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html);
see my
>> answer there in a couple of minutes.
>>
>>>
>>> - Clearly updating the readme and such would be appropriate.
>>> - I suspect we should change the name of the installed library.
'libiomp'
>>> is pretty clearly the Intel library. We could continue in the grand
>>> tradition of LLVM naming conventions and use 'libllomp'? Of
course, we
>>> should install symlinks under the name 'libiomp' if needed
for existing
>>> users to not be broken.
>>> - Any other changes?
>>
>>
>> Adding openmp-dev list (in retrospect, should have been done at the
very
>> start...), Jim Cownie and Andrey Churbanov.
>>
>>>
>>> 2) I think we need to update the instructions for checking out LLVM
and
>>> all the tools to include checking out the openmp project. I'm
planning to
>>> try it out in a bit.
>>
>>
>> Cool! Thank you!
>>
>>>
>>> 3) It would be nice to get at least one boring benchmark into the
>>> test-suite that uses OpenMP just so there's more coverage that
the basic
>>> stuff all works. In particular, if we could get the benchmark that
Phoronix
>>> and others keep pointing at, that'd be nice.
>>
>>
>>> Speaking of which, have you checked the performance of some of the
basic
>>> benchmarks using OpenMP with the two runtimes? Or looked at Clang
vs GCC
>>> there? I'd be interested to see the numbers.
>>
>>
>> This is very tricky for me -- I'm employed by a CPU vendor (Intel),
and we
>> have very strict rules and long processes for publishing benchmark
results.
>> I simply can't run a benchmark and say: "hey! clang has this
number and gcc
>> has that number".
>>
>> The only thing I can share is that we do tested SPEC OMP2012
>> (https://www.spec.org/omp2012/), which is the industry standard for OMP
>> benchmarks, on a non-server class Darwin machine, and the results are
quite
>> good and comparable with other compilers.
>>
>> Speaking on Phoronix, two benchmarks where clang always lose due to
lack
>> of OpenMP are "John the Ripper"
>>
(http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3)
>> and ImageMagick -- though latter is not included in most recent
"clang vs
>> gcc" comparison.
>>
>> Is there a generous soul (not employed by a CPU vendor :-)) willing to
run
>> "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
>> -lm -O3" and compare results with "clang -O3"?
>
>
> Attached are preliminary benchmarking of John the Ripper 1.8.0 for clang
> 3.7svn with the two outstanding OPENMP patches applied and for gcc 5.1.0.
> The attached john_the_ripper_clang-3.7.log and  john_the_ripper_gcc-5.1.log
> files contain the benchmarks at -O2 and -O3 for each compiler. As before,
> the runs are from x86_64-apple-darwin14 using a early 2008 MacPro with dual
> 2.8GHz quad-core Xeon processors and 10 Gb of memory.
>
>>
>> Also, Jack Howarth did testing with some other benchmarks, and it is
nice
>> to see that clang + libiomp compare quite well (to say it mildly ;-))
with
>> gcc + libgomp!
>>
>> Andrey
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>

Jack,

Could you, please, submit a bug report? -- including steps to
reproduce (where you got imageMagick sources, how exactly you compiled
them, etc)

Andrey


On Fri, May 1, 2015 at 3:56 PM, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
>
>
> On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at
gmail.com>
> wrote:
>>
>> Chandler,
>>
>> Thanks for the reply -- I always included you in libiomp supporters
camp;
>> it is good to see I wasn't mistaken! ;-)
>>
>> On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at
google.com>
>> wrote:
>>>
>>> Is there no way to support libgomp here as well? I don't say
this to hold
>>> up changing the defaults in any way, just curious. =]
>>
>>
>> No, sorry. libgomp doesn't support Intel API and clang generates
Intel API
>> calls only -- as simple as that. Someday someone may implement
generation of
>> GNU API calls as well, but this is a separate big task that, IMHO,
doesn't
>> serve any real purpose -- and potentially introduces nasty GPL-related
legal
>> issues.
>>
>> There is an option to choose what library clang links
>> (-fopenmp={libiomp|libgomp}), though.
>>
>>>
>>> I totally agree, I think things are way better now. I generally
support
>>> the direction. I think there are a few things I'd suggest we do
as part of
>>> the process, but I think these are really small and just about
"how" we
>>> switch.
>>>
>>> 1) I completely agree with the comments some others have made about
us
>>> needing to make it clear that this isn't some Intel-only thing,
its the LLVM
>>> OpenMP runtime. Some suggestions that I think would make sense to
help here:
>>> - I agree with finding some non-Intel folks to add as explicit code
>>> owners. I don't know who has been sufficiently involved, but if
Hal makes
>>> sense, awesome.
>>
>>
>> This really belongs to a separate thread
>> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html);
see my
>> answer there in a couple of minutes.
>>
>>>
>>> - Clearly updating the readme and such would be appropriate.
>>> - I suspect we should change the name of the installed library.
'libiomp'
>>> is pretty clearly the Intel library. We could continue in the grand
>>> tradition of LLVM naming conventions and use 'libllomp'? Of
course, we
>>> should install symlinks under the name 'libiomp' if needed
for existing
>>> users to not be broken.
>>> - Any other changes?
>>
>>
>> Adding openmp-dev list (in retrospect, should have been done at the
very
>> start...), Jim Cownie and Andrey Churbanov.
>>
>>>
>>> 2) I think we need to update the instructions for checking out LLVM
and
>>> all the tools to include checking out the openmp project. I'm
planning to
>>> try it out in a bit.
>>
>>
>> Cool! Thank you!
>>
>>>
>>> 3) It would be nice to get at least one boring benchmark into the
>>> test-suite that uses OpenMP just so there's more coverage that
the basic
>>> stuff all works. In particular, if we could get the benchmark that
Phoronix
>>> and others keep pointing at, that'd be nice.
>>
>>
>>> Speaking of which, have you checked the performance of some of the
basic
>>> benchmarks using OpenMP with the two runtimes? Or looked at Clang
vs GCC
>>> there? I'd be interested to see the numbers.
>>
>>
>> This is very tricky for me -- I'm employed by a CPU vendor (Intel),
and we
>> have very strict rules and long processes for publishing benchmark
results.
>> I simply can't run a benchmark and say: "hey! clang has this
number and gcc
>> has that number".
>>
>> The only thing I can share is that we do tested SPEC OMP2012
>> (https://www.spec.org/omp2012/), which is the industry standard for OMP
>> benchmarks, on a non-server class Darwin machine, and the results are
quite
>> good and comparable with other compilers.
>>
>> Speaking on Phoronix, two benchmarks where clang always lose due to
lack
>> of OpenMP are "John the Ripper"
>>
(http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3)
>> and ImageMagick -- though latter is not included in most recent
"clang vs
>> gcc" comparison.
>
>
> Unfortunately, the current llvm 3.7svn and available OPENMP patches
don't
> allow for imageMagick-6.8.2 to compile. The build fails on the compiler
> error...
>
> magick/attribute.c:331:12: error: loop iteration variable in the associated
> loop of 'omp parallel for' directive may not be threadprivate or
thread
> local, predetermined as
>       private
>       for (i=0; i < (ssize_t) image->colors; i++)
>            ^
> magick/attribute.c:325:9: note: loop iteration variable is predetermined as
> linear
>         i;
>         ^
> magick/attribute.c:978:12: error: loop iteration variable in the associated
> loop of 'omp parallel for' directive may not be threadprivate or
thread
> local, predetermined as
>       private
>       for (i=0; i < (ssize_t) image->colors; i++)
>            ^
> magick/attribute.c:972:9: note: loop iteration variable is predetermined as
> linear
>         i;
>         ^
> 2 errors generated.
>
> I get the same error when I try to build the latest ImageMagick 6.9.1-2
> sources with clang 3.7svn using -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5.
>
>>
>> Is there a generous soul (not employed by a CPU vendor :-)) willing to
run
>> "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
>> -lm -O3" and compare results with "clang -O3"?
>>
>> Also, Jack Howarth did testing with some other benchmarks, and it is
nice
>> to see that clang + libiomp compare quite well (to say it mildly ;-))
with
>> gcc + libgomp!
>>
>> Andrey
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>