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 3.6.0 for Debian buster
7 messages · Johannes Ranke, Dirk Eddelbuettel, 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). 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
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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
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? 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
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 ... 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
_______________________________________________ R-SIG-Debian mailing list R-SIG-Debian at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
PD Dr. Johannes Ranke Grenzach-Wyhlen
On 29 April 2019 at 15:03, Kurt Hornik wrote:
| >>>>> 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 ...
From what I saw, the change is triggered by 'lto' -- link-time optimisation.
A genuinely desirable feature (which can lead to improved performance from 'whole program' view) which however appears to have a side effect with older Fortran code and its calling convention. Note, however, that Debian unstable still has the 8.3.* branch. As such I would find that it is a little early to ring alarm bells at full tilt. CCing Martyn who use the R Foundation twitter handle for one such alarm. Without commensurate discussion on r-devel or r-package-devel this may not help much. Dirk | | 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 at r-project.org | >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian | | _______________________________________________ | R-SIG-Debian mailing list | R-SIG-Debian at r-project.org | https://stat.ethz.ch/mailman/listinfo/r-sig-debian
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Dirk Eddelbuettel writes:
On 29 April 2019 at 15:03, Kurt Hornik wrote: | >>>>> 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 ...
From what I saw, the change is triggered by 'lto' -- link-time optimisation. A genuinely desirable feature (which can lead to improved performance from 'whole program' view) which however appears to have a side effect with older Fortran code and its calling convention.
Note, however, that Debian unstable still has the 8.3.* branch. As such I would find that it is a little early to ring alarm bells at full tilt. CCing Martyn who use the R Foundation twitter handle for one such alarm. Without commensurate discussion on r-devel or r-package-devel this may not help much.
Dirk: Martyn has a first tweet coming up shortly. The change is actually not triggered by lto, but illustrated. From what we learned, calling Fortran from C without the additional character length arguments for character arguments (as done in the R API) now works differently as before, breaking at least about 25 CRAN packages, half of which with segfaults. And that compiler change is in the trunk since several months but was ported to gcc-8-branch about a month ago, and more or less immediately picked up in the gfortran-8 package in testing/unstable ... -k
Dirk
| | 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 at r-project.org | >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian | | _______________________________________________ | R-SIG-Debian mailing list | R-SIG-Debian at r-project.org | https://stat.ethz.ch/mailman/listinfo/r-sig-debian
-- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org