I am AFK at the moment, but I will be back tomorrow.
In the meantime, there are a few things that you could do.
Could you check with the most recent trunk and see if this persists? The original code had a problem with ENTRY that has been fixed recently.
Can you open a PR and mark it as [8/9 Regression] ?
Regarding a test case, you could try the following, not necessarily in that order.
Could you try compiling the code with -flto and see if you get any mismatches/warnings, and check if they are valid or not? (It is quite possible that the change exposed an interface problem in the code).
If it is F77, you could also run ftnchek on it, if you do not do do already on a regular basis?
To get a backtrace, compile with -g and run a segfaulting test case, that should give you a location and a backtrace. If that does not work, you can also try running under a debugger or under valgrind.
See what the code does with -Wall -fcheck=all -g.
The most importent thing now is to get a test case.
> Am 18.04.2019 um 14:48 schrieb Kurt Hornik <[hidden email]>:
> Dear Thomas,
> Please allow me to contact you directly on behalf of the teams
> developing R ("GNU S", <https://www.R-project.org>) and maintaining the
> Comprehensive R Archive Network (CRAN, <https:://CRAN.R-project.org>).
> We have identified a severe gfortran problem caused by changesets
> c268992 in the trunk and c269349 in gcc-8-branch which unfortunately we
> cannot condense into a simple bug report.
> R itself ships with LAPACK sources taken from Netlib, including a file
> dlapack.f created from LAPACK 3.8.0. CRAN provides a repository of more
> than 14000 extension packages for R. These packages are checked rather
> frequently, which includes running the R code provided in the docs and
> tests of these packages. We recently (Brian Ripley when using a local
> build from the trunk, myself after a recent upgrade of the Debian
> testing GCC 8.3 packages) observed check errors in about 20 CRAN
> packages, manifesting either as segfaults or as run time errors like (in
> fact, mostly)
> BLAS/LAPACK routine 'DTRTI2' gave error code -5
> These problems reproducibly occur when compiling R's dlapack.f using
> gfortran-9 at least r268992, or gfortran-8 at least r269349). Brian
> Ripley confirmed that for local GCC builds from the trunk, all the
> segfaults and DTRTI2 errors are gone with r268991 (and R re-compiled
> with that version) and re-appear when recompiling dlapack.f with
> r268992. I can confirm the equivalent changes when going from r269348
> to r269349 in gcc-8-branch.
> Prof. Ripley's knowledge of Fortran by far exceeds mine, but the
> changesets are about the compiler and not the runtime, and hence way out
> of our depth.
> We are of course happy to test possible fixes using our local setups:
> please let us know how we can help.
> Clearly, it would be very good to have the problem fixed (or the change
> backed out) for the GCC 9 release.
> CC'ing Matthias as the Debian GCC maintainer: any chance you could
> provide a new gfortran-8 with c269349 in gcc-8-branch backed out?
prompted by this report, I ran Lapack with a recent gfortran.
We really should do this more often.
This resulted in:
The latest one (stack overflow in the testing routines)
might also be relevant to this bug report. Does the problem go
away if the stack size is increased?
In reply to this post by Thomas König
When I set my stack size with:
ulimit -s 65535
lapack compiles and passes all tests with gfortran trunk.
$ gfc -v
Using built-in specs.
Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
--enable-languages=c,c++,fortran --enable-checking=release --enable-libgomp
Thread model: posix
gcc version 9.0.1 20190323 (experimental) (GCC)
--> LAPACK TESTING SUMMARY <--
Processing LAPACK Testing output found in the TESTING directory
SUMMARY nb test run numerical error other error
================ =========== ================= ================
REAL 1292645 0 (0.000%) 0 (0.000%)
DOUBLE PRECISION 1293457 0 (0.000%) 0 (0.000%)
COMPLEX 745040 1 (0.000%) 0 (0.000%)
COMPLEX16 753628 0 (0.000%) 0 (0.000%)
--> ALL PRECISIONS 4084770 1 (0.000%) 0 (0.000%)
In reply to this post by Thomas König
> With this email I am branching off the thread started by Prof Kurt Hornik
> from WU Vienna which we had about some LAPACK issues in gfortran 9. I
> mentioned this in passing in a github discussion for the RcppArmadillo
> package I maintain: https://github.com/RcppCore/RcppArmadillo/issues/254
Thanks for the link.
> Mathhew, CC'ed, possibly has a related bug from dtrti2. Would you be
> interested in a (reproducible) bug report?
Very much so. We (the gfortran team) need a test case so we can
start working on this.
> We tend to use Armadillo (a nice
> C++ library) on top of lapack -- would that be of help, or not?
We would prefer a minimum test case needed to reproduce the bug.
However, if you find that you have trouble reducing the case
any further, please do not hesitate to submit it as it is, we will
then try to work with it as you send it.
If possible (and especially if you have several files), it would
be best to submit a PR at https://gcc.gnu.org/bugzilla/ ,
with a self-contained test case.
|Free forum by Nabble||Edit this page|