>>>>> Johannes Ranke writes: Johannes,
It seems that one can avoid the gfortran problems with Fortran BLAS/LAPACK implementations by compiling with -fno-optimize-sibling-calls. Tomas recently wrote to R Core that ********************************************************************* - gfortran is leaning to (but no official announcement decision has already been reached) making -fno-optimize-sibling-calls the default as not to break BLAS/LAPACK, at least temporarily to give BLAS/LAPACK authors some time to fix - gfortran developers started discussing the issue with reference lapack maintainers on github, suggesting that the reference should use wrappers using portable C bindings using BIND(C) (which I've been suggesting to the gfortran developers as I saw it in "Numerical Computing with Modern Fortran" but of course they would have known too) ********************************************************************* See https://github.com/Reference-LAPACK/lapack/issues/339 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 for more information. Yesterday I changed R-devel and R-patched to use -fno-optimize-sibling-calls for gfortran >= 7: it would be great if you could pull this change into the R 3.6.0 backports for buster. In principle I think all Fortran BLAS/LAPACK implementations (refblas and ATLAS) packaged for buster should be recompiled with -fno-optimize-sibling-calls (they may be fine in case they were compiled with older version of gfortran-8, but then the next rebuild will cause trouble): Dirk, any chance you could get the package maintainers to make these changes? Best -k > Am Montag, 29. April 2019, 15:03:54 CEST schrieb Kurt Hornik: >> >>>>> Johannes Ranke writes: >> > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik: >> >> >>>>> Johannes Ranke writes: >> >> Thanks. You may have seen that with current gfortran in >> >> testing/unstable, there are problems with the R BLAS/LAPACK API entries >> >> using a Fortran interface (and hence in particular when using the BLAS >> >> and LAPACK sources that ship with R). >> > >> > No, I wasn't aware of this. Is there a bug report where this is >> > discussed? >> >> Not really, as the issue seems to complicated to condense into a bug >> report. From discussions with Thomas Koenig from the GCC team, it seems >> that f2c, g77 and now gfortran have always added additional character >> length arguments for each character argument, where the R >> F77_NAME/F77_CALL mechanism has always called with the arguments of the >> Fortran subroutine but without the additional length arguments. A >> change in gcc trunk also ported to gcc-8-branch apparently changed what >> happened in such case, to the effect that we're now seeing about 25 >> CRAN packages fail their run time checks with segfaults or run time >> errors ... >> >> But things are actually hard to pin down for us, and no obvious "fix" >> is in sight. It would be great if at least for the gfortran-8 that >> Debian will release we would get the old behavior back ... > I think the likelihood of this would be greater if there was a bug against > the > version of gfortran in unstable/testing... Can you give a small reproducible > example? > Johannes >> >> Best >> -k >> >> > Johannes >> > >> >> It seems I can avoid these using >> >> OpenBLAS (but then this really only works find for me provided I setenv >> >> OPENBLAS_NUM_THREADS=1). >> >> >> >> -k >> >> >> >> > Dear all, >> >> > Now that the upcoming Debian release "buster" is frozen, I have started >> >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is >> >> > now >> >> > available for Debian buster on i386 and amd64 architectures. Please >> >> > refer >> >> > to> >> >> > >> >> > https://cran.r-project.org/bin/linux/debian/ >> >> > >> >> > for details. At the moment I am not providing binaries for the arm >> >> > architecture for buster, as the SD card in my raspberry 3 has died and >> >> > I >> >> > do >> >> > not use these binaries any more anyways. Let me know if this is a >> >> > problem. >> >> > >> >> > Kind regards, >> >> > >> >> > Johannes >> >> > >> >> > _______________________________________________ >> >> > R-SIG-Debian mailing list >> >> > R-SIG-Debian@r-project.org >> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian >> >> _______________________________________________ >> R-SIG-Debian mailing list >> R-SIG-Debian@r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-debian > -- > PD Dr. Johannes Ranke > Grenzach-Wyhlen _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
