On 24/10/2008 6:53 PM, Dave Roberts wrote:
Colleagues,
I have a routine in package labdsv that calls a FORTRAN subroutine.
Recently, I was informed that it sometimes gives different results on a
PC and Mac, and that the PC version is clearly wrong. I tested it on
linux (because I don't have a PC), and I get the same (incorrect)
behavior as the PC.
Simply by inserting debug WRITE statements in the FORTRAN I would get
different, and correct, results, so I assumed it was an optimization
error.
So,
1) R CMD SHLIB duleg.f does not work, and produces bogus code
however,
2) gfortran -c alt_duleg.f
gcc -O -std=gnu99 -shared -L/usr/local/lib -o alt_duleg.so
alt_duleg.o -lgfortran -lm -lgcc_s
does work (note the -O low optimization). Otherwise the gcc command is
identical to the one produced by R CMD SHLIB.
Has anyone else seen this? Is there a simple way to have my package
enforce no optimization so others don't struggle with this? As far as I
know the same code worked under g77.
I haven't heard of this before, but I think we would be very interested
in hearing of cases where our default level of optimization produces
incorrect results. This could be a compiler bug, which we would want to
work around. It might also be an unstable algorithm, in which case you
probably should fix it, but you might choose instead to use Makevars or
Makefiles in your package to explicitly describe how you want it built.
Would it be possible for you to extract a minimal example that
illustrates the bug?
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
