[R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

>>>>> 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 using r-project.org
>> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>> 
>> _______________________________________________
>> R-SIG-Debian mailing list
>> R-SIG-Debian using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


> -- 
> PD Dr. Johannes Ranke
> Grenzach-Wyhlen