Thanks Berend,
Yes, I know about these warnings, they are mostly a consequence of the
automated
translation from the ancient Bell Labs dialect of fortran called ratfor. It is
easy to add
type declarations for “in” and the others, but it seems unlikely that this is
going to fix
anything. The
On 8/4/19 7:26 AM, Berend Hasselman wrote:
> Roger,
>
> I have run
>
> gfortran -c -fsyntax-only -fimplicit-none -Wall -pedantic rqbr.f
>
> in the src folder of quantreg.
>
> There are many warnings about defined but not used labels.
> Also two errors such as "Symbol ‘in’ at (1) has no IMPL
Roger,
On 4 August 2019 at 06:48, Koenker, Roger W wrote:
| I’d like to solicit some advice on a debugging problem I have in the quantreg
package.
| Kurt and Brian have reported to me that on Debian machines with gfortran 9
|
| library(quantreg)
| f = summary(rq(foodexp ~ income, data = engel,
Roger,
I have run
gfortran -c -fsyntax-only -fimplicit-none -Wall -pedantic rqbr.f
in the src folder of quantreg.
There are many warnings about defined but not used labels.
Also two errors such as "Symbol ‘in’ at (1) has no IMPLICIT type".
And warnings such as: Warning: "Possible change
A reply from stackoverflow suggests I might have hit this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14023
I can confirm that this glibc bug affects my system (latest CentOS 7).
However, as far as I know, R is not multithreaded in its core. Is it
possible that some library triggered th