Varmat for log_inv_logit fails at runtime

[WardBrian]

Description

log_inv_logit compiles but segfaults when called on a varmat object.

Example

See this model from the forums, originally reported by @spinkney.

For a smaller example, consider just:

parameters {
  vector[10] p;
}

model{
  target += sum(log_inv_logit(p));
}

If you compile this with O1, the result is

Program received signal SIGSEGV, Segmentation fault.
stan::math::log_inv_logit_fun::fun<stan::math::var_value<Eigen::Matrix<double, -1, 1, 0, -1, 1>, void> > (x=...)
    at stan/lib/stan_math/stan/math/prim/fun/log_inv_logit.hpp:67
67          return log_inv_logit(x);

Expected Output

I expected either this to fail at compile time (in which case we can just mark log_inv_logit as not SoA compatible in stanc3) or to not segfault.

Current Version:

v4.4.0

[SteveBronder]

This is technically a stanc3 bug in that I accidentally set log_inv_logit to SoA when it is not supported (I thought I got all the unary functions but I'll double check).

I just put up a PR to do this #2806 though we could just turn off SoA for log_inv_logit in the compiler for now and then add it back once that PR goes in

[andrjohns]

@SteveBronder Would it be worth expanding the apply_scalar_unary and apply_scalar_binary frameworks to take varmat inputs regardless? There's going to be a performance cost when the function doesn't have a specialisation, but it would avoid compilation errors/segfaults like these.

I've put together an initial idea over in this branch if you want to take a look: https://github.com/stan-dev/math/compare/develop...andrjohns:issue-2804-varmat-log_inv_logit?expand=1

[syclik]

I just verified that this still happens with develop right now. I'll try with the code from PR #2806 to see if that helps.

[syclik]

I valided that #2806 fixes this issue.

[SteveBronder]

Closed with #2806 merged