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
>>>>> 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 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 9 May 2019 at 16:35, Kurt Hornik wrote:
| >>>>> 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?
If I make them in Debian package it usually just flows to Johannes (for
Debian backports) and Michael (for Ubuntu) as those two gentlemen are very
reliable too.
Kurt, there is one thing that has been bugging me too and I was wondering if
I could lean on you as I have not had time work it out. It seems that one
"should" be to set an environment variable to suppress additional
"non-portable compiler flags used" warnings. We get those from Debian
as
distro-imposed flags I cannot ("should not") override; they are
everywhere:
Debian, backport, Ubuntu, Michael's PPA, hence Travis, ... and users are
confused (see e.g. r-package-devel).
Can you and I pretty-please work either a quick patch we fold in, or a set
set via an environment variable in the Renviron.site we ship? I couldn't
make the latter approach work yet.
Example from most recent Travis build of mine:
* checking compilation flags used ... NOTE
Compilation used the following non-portable flag(s):
?-Werror=format-security? ?-Wformat?
* checking compiled code ... OK
Source https://travis-ci.org/eddelbuettel/digest/builds/530216741
Happy to take off-list.
Dirk
| 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 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
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Kurt, Am Donnerstag, 9. Mai 2019, 16:35:24 CEST schrieb 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....> 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.Thanks, that sounds good. But I need some help as I do not know much about autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) or do we need to update configure as well (r76468)?> 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?It seems to me this is of relevance for for S?bastien (Ccing), or more generally for debian-science. Kind regards, Johannes> > 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 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