Re: [Rd] gfortran optimization problems

From: Duncan Murdoch <>
Date: Fri, 24 Oct 2008 18:55:16 -0400

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.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 mailing list Received on Fri 24 Oct 2008 - 22:58:06 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 25 Oct 2008 - 05:30:27 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive