[Rd] gfortran optimization problems

[Duncan Murdoch]

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