Compiling with O1 leads to failing chains with compound declaration and assignment with range indices about math HOT 7 CLOSED

This appears to be an issue with assigning to the SoA matrix type.

The specific error is a segmentation fault in
void stan::model::internal::assign_impl<stan::math::var_value<Eigen::Matrix<double, -1, 1, 0, -1, 1>, void>&, stan::math::var_value<Eigen::VectorBlock<Eigen::Map<Eigen::Matrix<double, -1, 1, 0, -1, 1>, 0, Eigen::Stride<0, 0> >, -1>, void>, (void*)0>(stan::math::var_value<Eigen::Matrix<double, -1, 1, 0, -1, 1>, void>&, stan::math::var_value<Eigen::VectorBlock<Eigen::Map<Eigen::Matrix<double, -1, 1, 0, -1, 1>, 0, Eigen::Stride<0, 0> >, -1>, void>&&, char const*)

Whether this issue should be transferred to stan-dev/stan or stan-dev/stanc3 depends on whether or not we think these vectors should be marked as SoA. If you change the code to x = y[:] it works fine, so I suspect this is a bug in the C++, not in the compiler's behavior

@SteveBronder thoughts?

from math.

I think this is an issue with the assign functions in the Stan repo. I can take a look tmrw. My best guess is an off by one error

from math.

I tried writing a test which exposes this in the Stan repo and found something interesting. The issue seems to be that x is not initialized before it is assigned to. E.g, this segfaults:

  var_value<Vec> x;
  auto y = conditionally_generate_linear_var_vector<Vec>(3, 10);

  assign(x, rvalue(y, "y", index_min_max(1,3)), "");

but this doesn't:

  var_value<Vec> x = conditionally_generate_linear_var_vector<Vec>(3,1);
  auto y = conditionally_generate_linear_var_vector<Vec>(3, 10);

  assign(x, rvalue(y, "y", index_min_max(1,3)), "");

This seems to be to be different than the behavior for non-SOA types which allow you to assign to them if they're uninitialized, I believe. We could try to address this in the compiler (by never omitting the initialization for SoA types) or we could improve the logic in assigning these types.

@SteveBronder thoughts?

from math.

This is the specific line that segfaults in math when the LHS is an uninitialized var matrix:

This is only triggered I believe if the RHS is a expression? Otherwise, this overload of operator= is used and no segfault occurs.

from math.

I can take a look at this today

from math.

I thought harder about this and think that this may be a bug in the compiler optimizations.

We do assume in the var_value that the value is not a nullptr, otherwise we have to have constant checks and throws everywhere. I think this is an issue with the optimization pass that removes the NA defaults if we immediately do an assignment. I'll look into this more tmrw

from math.

I have an old compiler branch which removed that pass from SoA types, I wasn’t sure if it was the “right” fix or not, since the behavior for these overloads of operator= is very different from the normal AoS ones

from math.