Compiling Rstan under clang++ (c++11)

[Robert J Goedman]

Hi,

Has anyone tried to install Rstan with 'clang++ -std=c++11 -stdlib=libc++' in R-devel on a Mac?

Thanks,
Rob J. Goedman
goe...@icloud.com

--------- DETAILS -------------

Following the standard route (CRAN builds, etc.) I have no problem with using Stan or Rstan.

Compiling stan with clang++ also works fine and finishes 'make o=0 test-unit' without any problems.

But recently I have been looking into compiling R and Rcpp, RcppArmadillo and RcppEigen using clang++ with the 2011 extensions. Rcpp, RcppArmadillo and RcppEigen all work and indeed I can compile lambda functions, say using Rstudio or using command line R on my Mac.

The next step was to try and compile Stan and Rstan using the same compiler flags.

The command line version of stan does generate, in addition to the 'warnings' I'd seen with just clang++, 'notes'  (e.g. lib/boost_1.53.0/boost/concept_check.hpp:521:15: note: in instantiation of member function),  but seems to work in the end (see stan-output.txt below, all the way at the end and sample.csv), although 'make o=0 test-unit' now fails (see test-output.txt).

Installation of Rstan produces similar error messages as making stan for command line usage, but now will fail as illustrated in bernoulli.txt.

I couldn't figure out how to present an easier, reproducible example.

[Ben Goodrich]

On Sunday, June 23, 2013 8:22:52 PM UTC-4, Rob J Goedman wrote:

The command line version of stan does generate, in addition to the 'warnings' I'd seen with just clang++, 'notes'  (e.g. lib/boost_1.53.0/boost/concept_check.hpp:521:15: note: in instantiation of member function),  but seems to work in the end (see stan-output.txt below, all the way at the end and sample.csv), although 'make o=0 test-unit' now fails (see test-output.txt).

You have to add -DBOOST_RESULT_OF_USE_TR1 to CFLAGS in the makefile. Even with that, test-unit will probably eventually fail for Stan v1.3.0, but it does pass on the origin/develop branch from Github as long as you don't try values of O_STANC greater than the default of 0.

Ben

[Ben Goodrich]

I said the wrong option. You actually need to add -DGTEST_USE_OWN_TR1_TUPLE to CFLAGS_GTEST in the makefile.

Ben

[Robert J Goedman]

Thanks Ben,

I'll try that tomorrow.

Sent from Rob Goedman's iPad ...

--
You received this message because you are subscribed to the Google Groups "stan users mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Daniel Lee]

Hi Rob,

Sorry for the delay. I don't have any insights into getting clang++ to work with rstan, but here are some things that might help:

- test-output.txt:
add an additional compiler flag -DGTEST_USE_OWN_TR1_TUPLE. That will get you past not being able to build test/gtest.o
- Rstan-output.txt: the error looks suspiciously like something went wrong inside ~/Projects/R/R_projects/Rstan/8schools/8schools.R. Can you attach that file? It looks like the schools code may be incorrect.
- bernoulli.txt: so the source file looks ok (it uses bivariate.R), but I think the Stan compiler (stanc) may not have been built properly. If both the 8schools and the bernoulli examples don't parse, something is going on.

Can you set the compilation flags to O=3? This is starting to look like a Windows issue where the Stan compiler can't be built at O=0, but that's the best guess I've got.



Daniel

> <stan-output.txt>
>
>
>
> <makefile.txt>
>
>
>
> <bernoulli.stan.txt>
>
>
> <bernoulli.cpp>
>
>
> <samples.csv>
>
>
> <test-output.txt>
>
>
> <Rstan-output.txt>
>
>
>
> <bivariate.R>
>
>
> <bernoulli.txt>
>
>
>
> Rob J. Goedman
> goe...@icloud.com

[Robert J Goedman]

Hi Daniel,

Thank you very much for the reply.

Indeed, as also Ben had suggested, after adding the extra flag 'make o=0 test-unit' successfully passes all 66 test after compiling stan with 'clang++ -std=c++11 -stdlib=libc++'.

I've attached 8schools.R below, but haven't changed that file for a while now and it runs fine with Rstan using CRAN R-3.0.1.

I'll try what happens with other levels of optimization when compiling stan.

What surprises me is:

1) Compiling stan and installing Rstan both create error messages as below (related to templating in the boost package?).

2) But while stan works, e.g. the standard bivariate example in src/models/... works fine, Rstan can't compile a 'similar' input file (bivariate.R, added below) with the console displaying:

-------------------- bivariate.R output --------------------------------------

> source('~/Projects/R/R_projects/Rstan/bivariate/bivariate.R')
Loading required package: stats4
rstan (Version 1.3.0, packaged: 2013-04-12 21:12:02 UTC, GitRev: f57455593d14)

TRANSLATING MODEL 'bivar' FROM Stan CODE TO C++ CODE NOW.
Error in stanc(file = file, model_code = model_code, model_name = model_name, :
failed to parse Stan model 'bivar' with error message:
EXPECTATION FAILURE LOCATION: file=input; line=12, column=2

}
^-- here


DIAGNOSTIC(S) FROM PARSER:
Parser expecting: "*/"

----------------------------------------------------------------------------------------

Still trying a few ways in understanding below compiler errors.

Regards,
Rob J. Goedman
goe...@icloud.com

robs-15inch-2:stan-src-1.3.0 rob$ make bin/libstan.a
clang++ -std=c++11 -stdlib=libc++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Wno-unused-function -Wno-tautological-compare -c -O3 -o bin/stan/agrad/rev/var_stack.o src/stan/agrad/rev/var_stack.cpp
clang++ -std=c++11 -stdlib=libc++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Wno-unused-function -Wno-tautological-compare -c -O3 -o bin/stan/math/matrix.o src/stan/math/matrix.cpp
clang++ -std=c++11 -stdlib=libc++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Wno-unused-function -Wno-tautological-compare -c -O3 -o bin/stan/agrad/matrix.o src/stan/agrad/matrix.cpp
ar -rs bin/libstan.a bin/stan/agrad/rev/var_stack.o bin/stan/math/matrix.o bin/stan/agrad/matrix.o
ar: creating archive bin/libstan.a
/usr/bin/ranlib: file: bin/libstan.a(matrix.o) has no symbols
robs-15inch-2:stan-src-1.3.0 rob$ make bin/stanc
clang++ -std=c++11 -stdlib=libc++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Wno-unused-function -Wno-tautological-compare -c -O3 -o bin/stan/command/stanc.o src/stan/command/stanc.cpp
In file included from src/stan/command/stanc.cpp:1:
In file included from src/stan/command/stanc_helper.hpp:2:
In file included from src/stan/gm/compiler.hpp:5:
In file included from src/stan/gm/generator.hpp:5:
In file included from lib/boost_1.53.0/boost/lexical_cast.hpp:169:
In file included from lib/boost_1.53.0/boost/range/iterator_range_core.hpp:26:
In file included from lib/boost_1.53.0/boost/range/functions.hpp:23:
In file included from lib/boost_1.53.0/boost/range/rbegin.hpp:19:
In file included from lib/boost_1.53.0/boost/range/reverse_iterator.hpp:20:
In file included from lib/boost_1.53.0/boost/iterator/reverse_iterator.hpp:12:
lib/boost_1.53.0/boost/iterator/iterator_adaptor.hpp:306:18: warning: returning reference to local temporary object [-Wreturn-stack-address]
{ return *m_iterator; }
^~~~~~~~~~~
lib/boost_1.53.0/boost/iterator/iterator_facade.hpp:514:20: note: in instantiation of member function
'boost::iterator_adaptor<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char,
std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted,
boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator,
boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char> > >,
boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >,
boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted,
boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator,
boost::spirit::iterator_policies::split_std_deque> >, const char, boost::forward_traversal_tag, boost::use_default,
boost::use_default>::dereference' requested here
return f.dereference();
^
lib/boost_1.53.0/boost/iterator/iterator_facade.hpp:639:18: note: in instantiation of function template specialization
'boost::iterator_core_access::dereference<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char,
std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted,
boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator,
boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char> > > >'
requested here
return iterator_core_access::dereference(this->derived());
^

lib/boost_1.53.0/boost/concept_check.hpp:521:15: note: in instantiation of member function

'boost::iterator_facade<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char,
std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted,
boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator,
boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char> > >,
const char, boost::forward_traversal_tag, const char &, long long>::operator*' requested here
(void)*i; // require dereference operator
^
lib/boost_1.53.0/boost/concept/usage.hpp:22:43: note: in instantiation of member function
'boost::InputIterator<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char,
std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted,
boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator,
boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char> > >
>::~InputIterator' requested here
~usage_requirements() { ((Model*)0)->~Model(); }

[Daniel Lee]

This is a long shot, but could you put a newline after the closing brace in the model?
Could you also save the file you just sent to a temporary directory and source it with verbose=TRUE? Something like:
source('~/Downloads/bivariate.R', verbose=TRUE)

> <8schools.R><bivariate.R>

[Robert J Goedman]

Hi Daniel,

Below the output. Also tried after added newline after the closing braces, that did adjust the 'expected failure location' to line 15 instead of line 14, but same problem.

Rob J. Goedman

goe...@icloud.com

> library(rstan)

Loading required package: Rcpp

Loading required package: inline

Attaching package: ‘inline’

The following object is masked from ‘package:Rcpp’:

    registerPlugin

Loading required package: stats4

rstan (Version 1.3.0, packaged: 2013-04-12 21:12:02 UTC, GitRev: f57455593d14)

> getwd()

[1] "/Users/rob"

> setwd("./Projects")

> getwd()

[1] "/Users/rob/Projects"

> source("./R/R_projects/Rstan/bivariate/bivariate.R", verbose=TRUE)

'envir' chosen:<environment: R_GlobalEnv>

encoding = "native.enc" chosen

--> parsed 9 expressions; now eval(.)ing them:

>>>> eval(expression_nr. 1 )

=================

> library(MASS)

curr.fun: symbol library

 .. after ‘expression(library(MASS))’

>>>> eval(expression_nr. 2 )

=================

> library(rstan)

curr.fun: symbol library

 .. after ‘expression(library(rstan))’

>>>> eval(expression_nr. 3 )

=================

> set.seed(1234)

curr.fun: symbol set.seed

 .. after ‘expression(set.seed(1234))’

>>>> eval(expression_nr. 4 )

=================

> N <- 10

curr.fun: symbol <-

 .. after ‘expression(N <- 10)’

>>>> eval(expression_nr. 5 )

=================

> y <- c(0,1,0,0,0,0,0,0,0,1)

curr.fun: symbol <-

 .. after ‘expression(y <- c(0,1,0,0,0,0,0,0,0,1))’

>>>> eval(expression_nr. 6 )

=================

> bivar <-

+ "

+   data {

+     int<lower=0> N;

+     int<lower=0,upper=1> y[N];

+   }

+   parameters {

+     real<lower=0,upper=1> theta;

+   }

+   m ..." ... [TRUNCATED] 

curr.fun: symbol <-

 .. after ‘expression(bivar <-’‘"’‘  data {’‘    int<lower=0> N;’‘    int<lower=0,upper=1> y[N];’‘  }’‘  parameters {’‘    real<lower=0,upper=1> theta;’‘  }’‘  model {’‘    for (n in 1:N) {’‘      y[n] ~ bernoulli(theta);’‘    }’‘  }’‘")’

>>>> eval(expression_nr. 7 )

=================

> dat <- list(N=N, y=y)

curr.fun: symbol <-

 .. after ‘expression(dat <- list(N=N, y=y))’

>>>> eval(expression_nr. 8 )

=================

> f <- stan(model_code=bivar, data=dat, verbode=TRUE)

TRANSLATING MODEL 'bivar' FROM Stan CODE TO C++ CODE NOW.

Error in stanc(file = file, model_code = model_code, model_name = model_name,  : 

  failed to parse Stan model 'bivar' with error message:

EXPECTATION FAILURE LOCATION: file=input; line=14, column=1

 ^-- here

DIAGNOSTIC(S) FROM PARSER:

Parser expecting: <model declaration>

> 

[Ben Goodrich]

On Tuesday, June 25, 2013 4:58:55 PM UTC-4, Rob J Goedman wrote:

I've attached 8schools.R below, but haven't changed that file for a while now and it runs fine with Rstan using CRAN R-3.0.1.

I'll try what happens with other levels of optimization when compiling stan.

What surprises me is:

1)        Compiling stan and installing Rstan both create error messages as below (related to templating in the boost package?).

2)        But while stan works, e.g. the standard bivariate example in src/models/... works fine, Rstan can't compile a 'similar' input file (bivariate.R, added below) with the console displaying:

If the parser (stanc) is compiled with optimization and you use C++11, then there will be a parser failure along the lines of what you found. There is some debate about whether this behavior is a bug on boost's part. Command-line Stan has O_STANC distinct from O so that you can compile stanc without optimization and the rest of stan with optimization. But rstan uses one optimization level for everything.

Maybe rstan 2.0 will make this distinction. But for now, if you want to use C++-11, you are pretty much stuck with command-line Stan. However, Stan doesn't use any C++-11 features, so I doubt it would have a noticeable effect on performance. We've been trying to get compliant with the C++11 standard for a while but mostly to make sure that we don't have any undefined behavior.

Ben
 

[Bob Carpenter]

Yikes. I didn't realize it didn't work as opposed to just
issuing a warning.

I wouldn't say there's a "debate" so much as speculation.

There's an issue in the way we're instantiating character
iterators in the parser having to do with references vs.
values. There has, perhaps not uncoincidentally, been a change
in the way the character iterators work in C++11.

I've written to the Boost list for the parser several times
with no response. We don't know how to debug this.

Any suggestions appreciated.

- Bob

[Ben Goodrich]

On Tuesday, June 25, 2013 10:21:11 PM UTC-4, Bob Carpenter wrote:

Yikes.  I didn't realize it didn't work as opposed to just
issuing a warning.

It works if stanc is not compiled with optimization, which is the default for command-line Stan. RStan has never done different optimization levels for stanc and the rest, because it either used what was in ~/.R/Makevars or did -O3. With the most recent version of R, we can actually behave like Stan does.

But I can't think of a reason why an RStan user should care about using --std=c++11 anyway.

Ben
 

[Robert J Goedman]

Agreed. For another project I want to use Rcpp/RcppArmadillo with C++11 extensions and ran into the issue.

Your and Bob's answers confirmed the behavior I noticed. Compiling Rstan with -O0 indeed solves the issue!

Thanks again for your help, regards,

Rob J. Goedman

goe...@icloud.com

[Bob Carpenter]

It'll be much more efficient to compile without C++11 and
with -O3. Something on the order of a factor of 5 or 10 times
faster.

Any suggestions on how to fix our C++11 incompatibilities
under optimization would be greatly appreciated! Even if we
could just diagnose whether the problem was ours or in the
Boost Spirit Qi parser lib.

- Bob

On 6/26/13 3:45 PM, Robert J Goedman wrote:

> goe...@icloud.com <mailto:goe...@icloud.com>

[Robert J Goedman]

Hi Bob,

I'll try if I can reproduce the problem in a simpler setting first.

Regards,
Rob

Sent from Rob Goedman's iPad ...

[Robert J Goedman]

Bob,

A couple of weeks ago we exchanged some emails about this subject and you suggested to see if this is a 'stan' problem or possibly in the Boost Spirit Qi (BSQ) parser. Some testing confirmed it is a parsing issue. Under O_STANC = 3 even the very first "data {..." was not recognized.

To make this problem reproducible, I ended up simplifying it all the way down to 2 grammars, a program-grammar and a whitespace-grammar which still show the problem. The resulting 'simplfied' source tree can be found at https://github.com/goedman/clang11-spirit-qi .

The whitespace-grammar is identical to the one used in Stan. The simplified program-grammar has very little to do anymore with Stan's syntax (but you'll recognize it :-).

It parses fine under O = 0, but differently under O = 3 (update line 7 in the Makefile). Under O = 3, it does not recognize 'prog {' etc. (see program.txt in the source tree).

Assuming the simplified source tree is in a directory ./stan-qi-problem and that is the current working directory of a Terminal, I do:

clear && rm parser && make parser && ./parser program.txt

I believe you mentioned that an email has gone out to the BSQ team but no response has been received. If you think it is useful to proceed with this investigation I could try to post this reproducible source tree to the BSQ team to see if that helps in getting a response (I know the tree is still more then a single main program, but testing goes pretty fast now).

A further request is whether a few list members can check this on their systems. On my MacbookPro I use below clang++ version:

Robs-15inch-2:stan-qi-problem rob$ clang++ --version
Apple LLVM version 5.0 (clang-500.1.63) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

It would be nice to know if this is clang, clang version and/or Mac specific.

Regards,
Rob J. Goedman
goe...@icloud.com

[Ben Goodrich]

On Monday, July 15, 2013 12:52:39 PM UTC-4, Rob J Goedman wrote:

It would be nice to know if this is clang, clang version and/or Mac specific.

It is good to have a small example whenever Boost gets around to addressing this, but we already know it isn't specific to the setup. I've hit it on Linux with the last few versions of clang. There should also be a problem with g++ depending on whether you specify --std=c++11 or leave --std out.

Ben