G++ on Ubuntu fails to build unit tests


Anybody see this yet?

g++ -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.66.0 -isystem lib/cvodes_2.9.0/include -isystem lib/idas-2.1.0/include -std=c++1y -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused-function -Wno-uninitialized -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe  -c -o test/unit/math/prim/scal/fun/step_test.o test/unit/math/prim/scal/fun/step_test.cpp
test/unit/math/prim/scal/fun/log_modified_bessel_first_kind_test.cpp:80:1: internal compiler error: in fold_convert_loc, at fold-const.c:2269
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
<builtin>: recipe for target 'test/unit/math/prim/scal/fun/log_modified_bessel_first_kind_test.o' failed
make: *** [test/unit/math/prim/scal/fun/log_modified_bessel_first_kind_test.o] Error 1
make: *** Waiting for unfinished jobs....
make -j4 ./test/unit/math/prim/scal/fun/lb_transform_test ./test/unit/math/prim/scal/fun/log1p_exp_test ./test/unit/math/prim/scal/fun/bessel_first_kind_test ./test/unit/math/prim/scal/fun/inv_logit_test ./test/unit/math/prim/scal/fun/log_diff_exp_test ./test/unit/math/prim/scal/fun/ibeta_test ./test/unit/math/prim/scal/fun/choose_test ./test/unit/math/prim/scal/fun/trigamma_test ./test/unit/math/prim/scal/fun/rising_factorial_test ./test/unit/math/prim/scal/fun/logical_and_test ./test/unit/math/prim/scal/fun/binary_log_loss_test ./test/unit/math/prim/scal/fun/exp_test ./test/unit/math/prim/scal/fun/positive_transform_test ./test/unit/math/prim/scal/fun/int_step_test ./test/unit/math/prim/scal/fun/log_mix_test ./test/unit/math/prim/scal/fun/log1m_test ./test/unit/math/prim/scal/fun/log_modified_bessel_first_kind_test ./test/unit/math/prim/scal/fun/squared_distance_test ./test/unit/math/prim/scal/fun/constants_test ./test/unit/math/prim/scal/fun/corr_transform_test ./test/unit/math/prim/scal/fun/log_rising_factorial_test ./test/unit/math/prim/scal/fun/step_test ./test/unit/math/prim/scal/fun/value_of_rec_test ./test/unit/math/prim/scal/fun/is_uninitialized_test ./test/unit/math/prim/scal/fun/fdim_test failed
exit now (02/20/18 07:06:36 EST)

g++ --version:

krzysztof@fit:~/packages/math-bugfix$ g++ --version
g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO


I just ran into the same issue. After some digging it seems to be a bug in Boost’s implementation of the lgamma function, not stan. Compiling a program that calls lgamma with integer 0 (i.e. lgamma(0)) causes the compiler error with g++.

The problem starts with line 79 in test/unit/math/prim/scal/fun/log_modified_bessel_first_kind_test.cpp:

79:    EXPECT_THROW(log_modified_bessel_first_kind(-2, 1), std::domain_error);

The value of -2 is then passed (as the variable v) to this section in prim/scal/fun/log_modified_bessel_first_kind.hpp

196:    out = log_sum_exp(v * log_half_z - lgam, lcons - lgamma(v + 2));

Where lgamma(v + 2) then evaluates to lgamma(0)

A simple workaround is to just change the test line to:

79:    EXPECT_THROW(log_modified_bessel_first_kind(-2.0, 1), std::domain_error);

So that the end call is to lgamma(0.0)


@sakrejda’s problem looked like a compiler error caused by a compiler bug.

@andrjohns, yours looks like it actually compiles, runs, but uses the int specification.

Krzysztof, I’ve never seen that error, but I also don’t try to push that far out with compilers. We’ve run into lots of compiler bugs over the years. This one doesn’t even give an informative message. Not sure where to turn next. Maybe @bgoodri would know.


lgamma(0.0) is also messed up on Boost but I think it gets circumvented somehow. The lgamma in C++14 evaluates to infinity when given zero as input.


Nope, definitely at compile-time.

After more digging it looks like it only happens with the -O3 flag. You can test it with:

#include <boost/math/special_functions/gamma.hpp>

int main() {
  return 0;
g++ -I lib/boost_1.65.1/ -O3 test.cpp

Will return the compiler error