Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)

2019-06-06 Thread Simon Urbanek
Jon,

some time ago Apple's clang has silently dropped -fopenmp so we were able to at 
least keep it in the flags even if it wasn't actually using it. Still, it was 
only dropping it, it wasn't actually generating any parallel code, so there was 
real point in using it. That's when we decided to use non-Apple clang since it 
has proper support for parallel code generation.

What you're pointing out is that more recent clang builds from Apple now do 
include the OMP generation pieces (in particular the pre-processor), they just 
don't ship any OpenMP-related headers or libraries. The problem is that it's 
hard to rely on something that is unsupported and works only on some systems. 
We could ship libomp (we already do - no need to get it from homebrew), but, 
for example, the omp.h headers from clang7 don't work with Apple's clang (you 
do need explicit -I.. and -lomp in addition to -Wp,-fopenmp because it's not 
only the pre-processor that needs to know about it).

Also note that "-Wp,-fopenmp" is a hack - just because Apple has not patched 
the pre-processor and only the front-end/linker to refuse it, it doesn't mean 
that it actually works properly. There is no guarantee that they made changes 
to the code-generation which break something in OpenMP since it's not not even 
included in any of their tests. Hence I'd say it's a quick hack if you don't 
want to to install clang7 that may or may not work depending on your code, but 
not something I'd trust in a release.

Cheers,
Simon



> On Jun 6, 2019, at 6:42 AM, Jon Clayden  wrote:
> 
> Dear all,
> 
> Lack of OpenMP support in Apple’s build of Clang is cited as one
> reason for not using it in CRAN builds, but this is only partly true:
> after installing libomp from Homebrew, I have been adding
> “-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my
> builds for a while, and everything seems to work OK.
> 
> I’m not sure how far back this support goes (and I haven’t tried the
> Xcode 11 tools yet), but is there any known reason not to take this
> approach, and if not, would it make sense for R’s configure script to
> try “-Wp,-fopenmp” when testing for OpenMP support?
> 
> All the best,
> Jon
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)

2019-06-06 Thread Jon Clayden
Hi James,

> > Lack of OpenMP support in Apple’s build of Clang is cited as one reason for 
> > not using it in CRAN builds
>
> From R 3.4.x forward, OpenMP has been enabled in CRAN builds as the toolchain 
> is using a custom compiler.

I’m aware of that, but this makes building packages from source more
complicated for users in my opinion, since they also have to install
the custom compiler toolchains. But whatever one’s views on that, I’m
suggesting that one reason given for not using Apple Clang may not be
entirely correct.

> > but this is only partly true: after installing libomp ***from Homebrew***, 
> > I have been adding
>
> Unfortunately, both Xcode and Xcode CLI do not ship clang with support for 
> OpenMP. By installing `libomp` from homebrew, the system is getting a 
> clang-compliant OpenMP compiler from the llvm formula. To check, please see:

Not at all. The libomp formula is standalone, with no dependency on
the llvm formula. See
https://github.com/Homebrew/homebrew-core/blob/master/Formula/libomp.rb.
I can assure you that I don’t have the llvm formula installed.

> which clang

/usr/bin/clang

All the best,
Jon

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)

2019-06-06 Thread Balamuta, James Joseph
Greetings and Salutations Jon,

> Lack of OpenMP support in Apple’s build of Clang is cited as one reason for 
> not using it in CRAN builds

From R 3.4.x forward, OpenMP has been enabled in CRAN builds as the toolchain 
is using a custom compiler.

You can see this with regard to the work done to enable OpenMP with 
RcppArmadillo with a configure script to detect the compiler:

https://github.com/RcppCore/RcppArmadillo/pull/170 
https://github.com/RcppCore/RcppArmadillo/pull/219 

> but this is only partly true: after installing libomp ***from Homebrew***, I 
> have been adding

Unfortunately, both Xcode and Xcode CLI do not ship clang with support for 
OpenMP. By installing `libomp` from homebrew, the system is getting a 
clang-compliant OpenMP compiler from the llvm formula. To check, please see:

which clang

I wish it were the case though... 

Sincerely,

JJB

On 6/6/19, 5:43 AM, "R-SIG-Mac on behalf of Jon Clayden" 
 wrote:

Dear all,

Lack of OpenMP support in Apple’s build of Clang is cited as one
reason for not using it in CRAN builds, but this is only partly true:
after installing libomp from Homebrew, I have been adding
“-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my
builds for a while, and everything seems to work OK.

I’m not sure how far back this support goes (and I haven’t tried the
Xcode 11 tools yet), but is there any known reason not to take this
approach, and if not, would it make sense for R’s configure script to
try “-Wp,-fopenmp” when testing for OpenMP support?

All the best,
Jon

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


[R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)

2019-06-06 Thread Jon Clayden
Dear all,

Lack of OpenMP support in Apple’s build of Clang is cited as one
reason for not using it in CRAN builds, but this is only partly true:
after installing libomp from Homebrew, I have been adding
“-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my
builds for a while, and everything seems to work OK.

I’m not sure how far back this support goes (and I haven’t tried the
Xcode 11 tools yet), but is there any known reason not to take this
approach, and if not, would it make sense for R’s configure script to
try “-Wp,-fopenmp” when testing for OpenMP support?

All the best,
Jon

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Warning on XCode / Command Line Tools 11

2019-06-06 Thread Prof Brian Ripley

On 06/06/2019 09:31, peter dalgaard wrote:

FWIW, no updates are suggested for the source-building machine in my office, 
also running Mojave. (June 5 was Constitution Day and Election Day, so I have 
been away from the machine until now.)


It stopping nagging me yesterday afternoon, so likely it was an Apple 
snafu.  (I heard from others who had been caught by this, and of course 
Apple allows for 'automatic' updating so this could happen in the 
background.)



We do need to keep an eye on the tools though. My current setup is an  -um- 
eclectic mix (*) of old and new tools, some of which are 32 bit, and this is 
going to be a problem in 10.15 Catalina. I did try getting the tools better in 
line with Simon's setup at some point, but there were hiccups and then I ran 
out of time and couldn't risk collateral damage.


You have a few months yet.  The residual 32-bit applications I have are 
from Adobe, e.g. old uninstallers.




-pd


(*) ="dogs dinner"


On 4 Jun 2019, at 17:10 , Prof Brian Ripley  wrote:

My Mojave machine today prompted me to update to version 11 of Command Line 
Tools (apparently 'beta 1', but I am not a Beta tester).

In short: don't do that (you can revert to 10.2.1 from the URL above, at least 
if your Apple ID has (free) developer privileges).

CoreFoundation.framework has been removed (and its headers are used in a couple 
of spots compiling R).

Further its seems that 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
 is no longer included and setting CPPFLAGS did not suffice.

Hopefully we will have solutions in due course, but that version is really for 
10.15 Catalina which is months away ('in the Fall', whenever that is).

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Warning on XCode / Command Line Tools 11

2019-06-06 Thread peter dalgaard
FWIW, no updates are suggested for the source-building machine in my office, 
also running Mojave. (June 5 was Constitution Day and Election Day, so I have 
been away from the machine until now.)

We do need to keep an eye on the tools though. My current setup is an  -um- 
eclectic mix (*) of old and new tools, some of which are 32 bit, and this is 
going to be a problem in 10.15 Catalina. I did try getting the tools better in 
line with Simon's setup at some point, but there were hiccups and then I ran 
out of time and couldn't risk collateral damage.

-pd


(*) ="dogs dinner"

> On 4 Jun 2019, at 17:10 , Prof Brian Ripley  wrote:
> 
> My Mojave machine today prompted me to update to version 11 of Command Line 
> Tools (apparently 'beta 1', but I am not a Beta tester).
> 
> In short: don't do that (you can revert to 10.2.1 from the URL above, at 
> least if your Apple ID has (free) developer privileges).
> 
> CoreFoundation.framework has been removed (and its headers are used in a 
> couple of spots compiling R).
> 
> Further its seems that 
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>  is no longer included and setting CPPFLAGS did not suffice.
> 
> Hopefully we will have solutions in due course, but that version is really 
> for 10.15 Catalina which is months away ('in the Fall', whenever that is).
> 
> -- 
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac