clang / g++ on my Debian laptop
Ben Goodrich
still the case now that I have clang 3.0. The error, after doing make
clean and make all, is eventually:
clang++ -O3 -Wall -g -DNDEBUG -I src -I lib -std=gnu++0x -I lib/
gtest/include -I lib/gtest -DGTEST_HAS_PTHREAD=0 -lpthread src/test/
agrad/agrad_eigen_test.cpp lib/gtest/src/gtest_main.cc ar/libgtest.a -
o test/agrad/agrad_eigen
In file included from src/test/agrad/agrad_eigen_test.cpp:8:
In file included from src/stan/agrad/matrix.hpp:6:
In file included from lib/Eigen/Dense:1:
In file included from lib/Eigen/Core:99:
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.6/include/
emmintrin.h:36:
/usr/lib/gcc/x86_64-linux-gnu/4.6/include/xmmintrin.h:102:19: error:
use of undeclared identifier '__builtin_ia32_addss'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
Such errors are apparently due to a GCC-ism, see:
http://clang.llvm.org/compatibility.html#vector_builtins
which also includes a conversion script. But it is not clear whether
stan will still build with g++ if we convert so that stan will build
(for me) with clang. Also unclear is why stan builds for some of you
with Macs under either g++ or clang.
Ben
Bob Carpenter
> For a long time, I could build stan with g++ but not clang. This is
> still the case now that I have clang 3.0.
Thanks for letting us know.
Can you do anything with Eigen in Clang? I'm wondering
how much of this is our fault versus how much is
intrinsic to Eigen.
Although it's not ideal, we'd be OK with requiring
g++ to build. Mainly because R uses g++ and running
through R is a non-negotiable requirement.
We need to get a linux machine over here and
start getting to the bottom of the cross-platform
build issues.
This is well beyond my knowledge of the vagaries of
C++ compilers. I'm guessing the Mac compilers have
a different set of __builtin functions.
Can you build other things using Eigen in Clang?
- Bob
Daniel Lee
without this flag? -std=gnu++0x
It was only meant to be included when the compiler is g++. It slipped
my mind that clang++ contains g++ (duh). I'll get a fix back up in a
few mins.
Daniel
Ben Goodrich
> Can you build other things using Eigen in Clang?
Not at the moment for me personally, although
http://eigen.tuxfamily.org/index.php?title=Main_Page#Compiler_support
unequivocally claims recent versions of clang are supported.
Ben
Ben Goodrich
> Ben, this may be a problem with my update to the makefile. Can you try
> without this flag? -std=gnu++0x
>
> It was only meant to be included when the compiler is g++. It slipped
> my mind that clang++ contains g++ (duh). I'll get a fix back up in a
> few mins.
I think that is unrelated, or at least it didn't make any difference
when I tried it just now.
Also, setting -DGTEST_HAS_PTHREAD=1 doesn't seem to do anything. I
still have to add -lpthread to the compiler flags to get it to build
with g++.
Also, there are a number of warnings when compiling with g++, most of
which seem minor (comparison between signed and unsigned integers
mostly).
Ben
Bob Carpenter
> On Dec 14, 1:45 pm, Bob Carpenter<c...@alias-i.com> wrote:
>
>
> http://eigen.tuxfamily.org/index.php?title=Main_Page#Compiler_support
>
> unequivocally claims recent versions of clang are supported.
That's encouraging, though their mailing list after
new releases tends to get clogged with incompatibilities.
They mostly seem to revolve around the same kind of low-level
platform-specific builtins you were seeing. Especially around
their fixed-size and aligned structures.
On 12/14/11 7:08 PM, Ben Goodrich wrote:
> Also, setting -DGTEST_HAS_PTHREAD=1 doesn't seem to do anything. I
> still have to add -lpthread to the compiler flags to get it to build
> with g++.
We'll try to get to the bottom of the -lpthread
dependencies. This is probably also related to some
of the ops we're using in Eigen. What I'll do
is create something independent of Stan that touches
all the Eigen ops we use with doubles and see if
that brings up the same issues.
We might wind up having to do platform-specific makes.
> Also, there are a number of warnings when compiling with g++, most of
> which seem minor (comparison between signed and unsigned integers
> mostly).
We'll clean up all the compiler errors like
unsigned ints. Clang generates some erroneous
function- and constant-not-used errors with things
defined in anonymous namespaces (it must be confusing
the per-file mangling to generate an actual namespace).
- Bob
Ben Goodrich
can (almost) be solved by installing the development files for clang.
Linux distributions are in the habit of splitting up libraries so that
people can install only the parts that they need. In my case, I needed
to do
apt-get install libeigen-dev
so that the proper *mmintrin.h files will be found before falling back
to the problematic ones in g++.
I added a sentence to this effect in README.txt .
However, it then could not find uintptr_t, so I added
#include<stdint.h>
to src/stan/memory/stack_alloc.hpp , which was actually mixed up in
the previous commit that added another parameterization of the beta
density (I hate subversion).
At that point, with clang++, make demo/gm works. However, make all
segfaults consistently on one of the tests
test/agrad/error_handling --gtest_output="xml:test/agrad/
error_handling.xml"
Running main() from gtest_main.cc
[==========] Running 15 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 15 tests from AgradDistributionsErrorHandling
[ RUN ] AgradDistributionsErrorHandling.CheckNotNanDefaultPolicy
[ OK ] AgradDistributionsErrorHandling.CheckNotNanDefaultPolicy
(0 ms)
[ RUN ] AgradDistributionsErrorHandling.CheckNotNanErrnoPolicy
Segmentation fault
make: *** [test/agrad/error_handling] Error 139
I don't know much about this Policy business so someone else should
have a look. On a related note, my implementation of the
aforementioned beta density is just
beta_ls_log(const T_y& y, const T_mu& mu, const T_theta& theta,
const Policy& = Policy()) {
T_mu alpha = mu * theta;
T_mu beta = (1.0 - mu) * theta;
return beta_log(y, alpha, beta, Policy());
}
The compiler didn't like me just passing Policy and insisted on
passing Policy(), so maybe I am doing something wrong.
Ben
Jiqiang Guo
6. If you intend to work on Clang C++ support, you may need to
Ben Goodrich
make demo/gm
I can then compile and run models. What is the error message that you
get?
On Jan 13, 11:01 pm, Jiqiang Guo <guoj...@gmail.com> wrote:
> Just to talk about what I have on Ubuntu regarding clang.
>
> I am using an old version of Ubuntu, which does not have clang3+.
> So I have to build myself. However, the problem for clang++ is that
> it could not find the libstdc++ header files. Even I tried to follow
Ben Goodrich
-std=c++0x
(and also possibly change -O0 to -03 for more speed), it will compile
(with some warnings) and run.
Apparently, clang with eigen has some conformance issues with the new C
++ standard, which we should probably raise on their lists.
Also, we should probably have some standardization with these per-
example makefiles.
On Jan 13, 11:32 pm, Jiqiang Guo <guoj...@gmail.com> wrote:
> For example, see the attached output by the following
> user@machine:~/Desktop/stan/src/models/bugs_examples/vol2/dugongs$ make >
> make.log 2>&1
>
>
>
>
>
>
>
>
> > After I do
>
> > make demo/gm
>
> > I can then compile and run models. What is the error message that you
> > get?
>
>
>
> 37KViewDownload
Ben Goodrich
> At that point, with clang++, make demo/gm works. However, make all
> segfaults consistently on one of the tests
>
> test/agrad/error_handling --gtest_output="xml:test/agrad/
> error_handling.xml"
> Running main() from gtest_main.cc
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from AgradDistributionsErrorHandling
> [ RUN ] AgradDistributionsErrorHandling.CheckNotNanDefaultPolicy
> [ OK ] AgradDistributionsErrorHandling.CheckNotNanDefaultPolicy
> (0 ms)
> [ RUN ] AgradDistributionsErrorHandling.CheckNotNanErrnoPolicy
> Segmentation fault
> make: *** [test/agrad/error_handling] Error 139
fixed in revision 530 with a
sed -i 's/var result;/var result = 0;/g' src/test/agrad/
error_handling_test.cpp
However, it raises some other issues. First, it only occurs under clang
++ and only with -03. So, it seems that what happens when a var is
uninitialized varies. Second, the error_handling_test.cpp uses
std::isnan rather than the isnan macro from boost, but I left that
alone.
But now make all works for me with clang.
Ben
Jiqiang Guo
warning: default template arguments for a function template
are a C++11 extension [-Wc++11-extensions]
class Policy = policy<> >
Bob Carpenter
On 1/13/12 10:01 PM, Ben Goodrich wrote:
> The problem of me not being able to build stan on Debian with clang
> can (almost) be solved by installing the development files for clang.
> Linux distributions are in the habit of splitting up libraries so that
> people can install only the parts that they need. In my case, I needed
> to do
>
> apt-get install libeigen-dev
>
> so that the proper *mmintrin.h files will be found before falling back
> to the problematic ones in g++.
Like I said, Linux users are tougher than the
rest of us.
> I added a sentence to this effect in README.txt .
Thanks.
> However, it then could not find uintptr_t, so I added
>
> #include<stdint.h>
Odd, that's supposed to be a system built-in.
But apparently it was part of the C99 additions,
so isn't built-in everywhere except stdint.h.
We need to go over all the includes. Each file
should be able to compile on its own, and right now,
they're depending on namespace-level usings and
being included in the right order.
> to src/stan/memory/stack_alloc.hpp , which was actually mixed up in
> the previous commit that added another parameterization of the beta
> density
> (I hate subversion).
Should we be using something else?
I hate changing systems once I learn one.
> At that point, with clang++, make demo/gm works. However, make all
> segfaults consistently on one of the tests
>
> test/agrad/error_handling --gtest_output="xml:test/agrad/
> error_handling.xml"
> Running main() from gtest_main.cc
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from AgradDistributionsErrorHandling
> [ RUN ] AgradDistributionsErrorHandling.CheckNotNanDefaultPolicy
> [ OK ] AgradDistributionsErrorHandling.CheckNotNanDefaultPolicy
> (0 ms)
> [ RUN ] AgradDistributionsErrorHandling.CheckNotNanErrnoPolicy
> Segmentation fault
> make: *** [test/agrad/error_handling] Error 139
>
> I don't know much about this Policy business so someone else should
> have a look.
Danie's the man for this job -- he wrote all
of our error policy stuff.
> On a related note, my implementation of the
> aforementioned beta density is just
>
> beta_ls_log(const T_y& y, const T_mu& mu, const T_theta& theta,
> const Policy& = Policy()) {
> T_mu alpha = mu * theta;
> T_mu beta = (1.0 - mu) * theta;
> return beta_log(y, alpha, beta, Policy());
> }
>
> The compiler didn't like me just passing Policy and insisted on
> passing Policy(), so maybe I am doing something wrong.
This is a tricky little pattern here. Bottom line is
that Policy is a (template) type and Policy() is a
constructed instance of type Policy.
Note that there is no variable name in that last argument.
This is intentional. We're only using Policy() for the
type inference! If we ever need an actual Policy instance,
we just construct one in the body of the function using
Policy().
This is apparently a very common pattern with policies.
Daniel went ahead and used the C++11 feature of allowing
default parameter types in function templates (they were
always allowed in class templates).
- Bob
Bob Carpenter
try to access a stan::agrad::var instances
vari* ptr. If they try to do anything with it,
it'll be a problem, and the behavior of using
an uninitialized pointer is not specified in
the standard.
This is also something that'll seg fault models,
which isn't good, because as I was telling Daniel,
not all of our users are like Ben and able to
pull up gdb and start tracing the error through C++.
At the cost of some potential slowdown, I can
have the behavior be that if someone tries to
access a variable that hasn't been initialized,
it can be:
A. set to 0
This is the behavior of a member variable, not the
behavior of a local variable, which is undefined
before it's initialized.
B. throw a (configurable) error
This would at least let people know why their
program crashed, though I won't be able to give
much diagnostic info on the variable in the model
as that's lost by the time you get to var.
- Bob
Ben Goodrich
> > (I hate subversion).
>
> Should we be using something else?
> I hate changing systems once I learn one.
right now, but for a project as complex as stan starting in late 2010
with a half-dozen people committing changes so far, it probably would
have been a better choice to go with something with more features.
> Danie's the man for this job -- he wrote all
> of our error policy stuff.
Ben
Ben Goodrich
inflicted problems with our tests. In this case,
var result;
// some stuff that doesn't affect result
if(std::isnan(result)) // segfault
So, I don't have a strong opinion about what to do in general, since
it was simple enough to initialize result here.
Ben
Bob Carpenter
wrote a model like this would be in trouble:
derived parameters {
double x;
double y;
y <- x * 2; // SEG FAULT, x not defined
}
or this:
derived parameters {
double y[3];
y[0] = 2; // SEG FAULT, y[0] not defined
}
- Bob
Ben Goodrich
constrained to be positive?
Bob Carpenter
for
double(0,1) x;
be strict or not? That is, do I use:
0 < x && x < 1
or
0 <= x && x <= 1
?
The transforms don't quite guarantee <= because
of underflow/overflow issues. And we're trying to
set up densities and derivatives to deal with limits
gracefully.
> Would setting the value to 0 cause problems if the parameter were
> constrained to be positive?
If you have
double(1,4) x;
and initialized to 0 and never reset it,
it will wind up failing tests which I'm about
to write for:
data: on read
transformed data: after transform
params: on inits, if any
transformed params: on write (NOT every leapfrog step, but I could)
Local variables can't get any constraints. (The
compiler's catching it if someone tries to declare
them as such, including cov_matrix, etc.; it's also
erroneously complaining if transformed data or transformed
params have constraints, because I wasn't going to check
for them.)
- Bob
