Fix: Optimizations crash on mod 0 partial evaluation

[WardBrian]

Crash found by fuzzing

Submission Checklist

• [x] Run unit tests
• Documentation
  • [ ] If a user-facing facing change was made, the documentation PR is here:
  • [x] OR, no user-facing changes were made

Release notes

Fixed an issue with the partial evaluator crashing on statements containing a mod-by-zero.

Copyright and Licensing

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the BSD 3-clause license (https://opensource.org/licenses/BSD-3-Clause)

[codecov[bot]]

Codecov Report

Merging #1351 (743d0dd) into master (d5c25b6) will increase coverage by 0.02%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1351      +/-   ##
==========================================
+ Coverage   89.36%   89.39%   +0.02%     
==========================================
  Files          65       65              
  Lines       10609    10607       -2     
==========================================
+ Hits         9481     9482       +1     
+ Misses       1128     1125       -3     

Files Changed	Coverage Δ
src/analysis_and_optimization/Partial_evaluator.ml	89.63% <100.00%> (+0.24%)	:arrow_up:
src/stanc/stanc.ml	81.88% <100.00%> (-0.26%)	:arrow_down:

... and 2 files with indirect coverage changes

[WardBrian]

64-bit ints

63, actually (one of OCaml's weirder defaults).

But yes, sounds like it could be an issue. Can you write down a model that experiences that problem?

[nhuurre]

Can you write down a model that experiences that problem?

model {
  array[1] int T = {1000000000 * 1000000000};
  print(T);
}

Compile with stanc --O1 and clang++ stops at

error: constant expression evaluates to 1000000000000000000 which cannot be narrowed to type 'int'

[WardBrian]

That actually seems like it is catching what would be a runtime error at compile time, (with a pretty clear error message, on gcc as well) so I guess it's not the end of the world?

If you compile without optimizations GCC actually warns you anyway:

../../ml/stanc3/big.hpp:101:59: warning: integer overflow in expression of type ‘int’ results in ‘-1486618624’ [-Woverflow]
  101 |       stan::model::assign(T, std::vector<int>{(1000000000 * 1000000000)},

[nhuurre]

Yes, overflows are always runtime errors, just like divide-by-zero. (The partial evaluator does some "runtime work" at compile time so runtime undefined behavior can turn into a compile-time crash.) We should try and catch them in stanc3 and not the C++ compiler.