-
-
Notifications
You must be signed in to change notification settings - Fork 193
Complex multiply issue in GCC15 #3182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Passes for me under the
|
I get the same failure as jenkins if I try in the fedora docker. Could be an aarch vs x86 thing?
|
Ahh yeah I can also reproduce the failures under the I also tried adding Odd. |
I think it's something optimisation-related, the test only fails with |
In my experience those are the most annoying ones... |
Narrowed it down a bit further, it only fails when mixing scalar & matrix arguments (not for both scalar or both matrix). It's also definitely caused by the vectorisation of loops. The tests pass with |
The plot continues to thicken. There's some interaction with the use of |
Here's a minimum test-case (essentially just extracting the relevant part of the test framework) to reproduce the error: #include <stan/math.hpp>
#include <stan/math/fwd.hpp>
int main() {
using stan::math::serialize_args;
using stan::math::serialize_return;
using stan::math::to_deserializer;
using stan::math::eval;
double d_scalar = 1.0;
Eigen::VectorXcd cd_mat(2);
cd_mat << 1, 2;
Eigen::VectorXd args = serialize_args(cd_mat, d_scalar);
auto g12 = [&](const auto& v) {
using complex_t = std::complex<stan::scalar_type_t<decltype(v)>>;
Eigen::Matrix<complex_t, -1, 1> vec(2);
vec << complex_t(v(0), v(1)), complex_t(v(2), v(3));
auto scal = v(4);
auto ret = eval(stan::math::multiply(vec, scal));
return ret(0).imag();
};
double fx_ad;
Eigen::VectorXd grad_ad;
Eigen::MatrixXd H_ad;
stan::math::hessian<double>(g12, args, fx_ad, grad_ad, H_ad);
double fx_fd;
Eigen::VectorXd grad_fd;
Eigen::MatrixXd H_fd;
stan::math::internal::finite_diff_hessian_auto(g12, args, fx_fd, grad_fd, H_fd);
std::cout << "grad_ad: " << grad_ad.transpose() << std::endl;
std::cout << "grad_fd: " << grad_fd.transpose() << std::endl;
}
|
@andrjohns that reduced case is passing for me (the full test is still failing) |
Ah yeah the reduced example doesn't trip the auto-vectorisation, you need to add But you can verify the Here's an even simpler reprex of the #include <stan/math.hpp>
#include <stan/math/fwd.hpp>
int main() {
using stan::math::fvar;
using fd = fvar<double>;
using ffd = fvar<fvar<double>>;
ffd scal = 1.0;
Eigen::Matrix<std::complex<ffd>, -1, 1> vec_fvar(2);
// Estimating the gradient for the imaginary part of first element
vec_fvar << std::complex<ffd>(1, ffd(fd(0, 1), fd(1, 0))),
2;
auto res = stan::math::multiply(vec_fvar, scal);
auto res_eval = stan::math::eval(res);
std::cout << "res: " << res(0).imag().d_.val_ << std::endl;
std::cout << "res_eval: " << res_eval(0).imag().d_.val_ << std::endl;
}
Which prints:
(where |
Interesting. Manually assigning to an Eigen::Matrix rather than using
this prints 0, 0. Comment out |
The definition of |
Maybe related? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 |
@andrjohns have you had a chance to look into this any more? I've talked to a few people who know a lot about compiler vectorization and they seemed to think that the compiler is probably assuming some maximum If that is indeed the case, I think we might be hosed unless we switch to using our own struct for complex numbers |
I'm not sure if it's related somehow, but I found a different bug when initialising complex vector types: https://gitlab.com/libeigen/eigen/-/issues/2931 I'll see what the Eigen devs say, hopefully there's some central Eigen config for complex type handling that we just need to add |
There is this, but it's unreleased. |
Caught by https://jenkins.flatironinstitute.org/blue/organizations/jenkins/Stan%2FBleedingEdgeCompilersMonthly/detail/BleedingEdgeCompilersMonthly/259/pipeline
The issue seems to be specific to
fvar<fvar<double>>
.c.f. #3006, though note that this is a runtime failure, not a compile failure.
cc @SteveBronder @andrjohns
Details
The text was updated successfully, but these errors were encountered: