https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124819
--- Comment #6 from Christopher Albert <albert at tugraz dot at> --- I checked this further and do not see a GCC source-regression commit to bisect. Between releases/gcc-15.2.0 and current trunk, the only relevant change is 77a8ed6de20b adding `dg-do run` to bessel_6.f90. `libgfortran/generated/bessel_r4.c` has no functional change in that range. A local build from releases/gcc-15.2.0 already fails with the same standalone reproducer when linked against its locally built libgfortran. I also isolated this to code generation of bessel_r4.c on my system: - generic build: FAIL - `-march=x86-64-v3 -mno-fma`: FAIL - `-march=x86-64-v3 -ffp-contract=off`: FAIL - `-mavx2 -mfma`: PASS - `-march=x86-64-v3 -mfma`: PASS The passing variants use fused multiply-subtract in `_gfortran_bessel_jn_r4`, while the failing ones use separate multiply/subtract operations. So this looks like a numerical-sensitivity issue in the REAL(4) recurrence, not a trunk source regression. The testsuite change exposed it, but did not introduce it.
