0

I've been using f2py to "pythonize" some Fortran codes for use on a 64-bit Windows 7 machine. I'm working with 64-bit Anaconda 4.2.0 and using MinGW installed via conda install mingw (the associated folders use the name "x86_64-w64-mingw32"). It was working well until I tried a program with quadruple precision (REAL*16) numbers. I found that the program crashed (libquadmath-0.dll was cited in the ProblemSignature of the Windows-generated crash report).

I tried to identify the simplest case that causes a problem. I ended up coming up with a fairly basic Fortran program that gives a "fatal error" under certain conditions:

      PROGRAM MAIN
      REAL*8 DL
      REAL*16 QL
      DL=2.71828
      QL=3.14159

C     when compiled with -ffpe-trap=overflow with MinGW distribution for 64-bit Anaconda, uncommenting either of the lines below breaks the program ("fatal error" at runtime)
C     however, the second line is acceptable if DL is changed to quad precision (REAL*16)
C     both lines are acceptable if both DL and QL are double precision (REAL*8)
      OPEN (79)
      print*, "DL=",DL

      print*, "Ready to print QL!"
      print*, "QL=",QL
      end

As indicated in the comments above, when I compile with the Anaconda MinGW package's gfortran with the compiler option -ffpe-trap=overflow, I get a fatal error. For example, with both lines uncommented (as above), I get:

 DL=   2.7182800769805908
 Ready to print QL!

A fatal error occurred! Backtrace for this error:
#0  ffffffffffffffff

(See comments in the code for further details about what happens with different variations.)

I have tried with a standard MinGW32 distribution that I have set up on the same computer (compiling and running within msys command line), and there are no issues.

I believe I have confirmed that the libquadmath-0.dll included with the anaconda mingw package is a 64-bit dll. I have not been able to identify any issues with environment variables, and I think I have ruled out the possibility that it is using my standard MinGW32 32-bit dll by temporarily renaming the MinGW32 directory.

Aside from the 32-bit vs. 64-bit difference, I have noticed that my MinGW32 gfortran is based on GCC 4.8.1, whereas the gfortran with the 64-bit Anaconda MinGW package is listed as using GCC "4.7.0 20111220 (experimental)". I'm not sure if that is related to the issue, but I couldn't find anything obvious in the GCC changelog that would account for the issues I'm seeing.

I'd very much appreciate any tips / solutions anyone can provide.

I'd be especially interested if anyone can reproduce this error with another 64-bit MinGW distribution. At the moment, I don't know if it is an issue with GCC/gfortran, MinGW, Anaconda, or something else peculiar to my own setup.

gmagoon
  • 11
  • 1
    What is ` OPEN (79)` supposed to do? I think your compiler installation is broken. – Vladimir F Героям слава Oct 26 '16 at 10:27
  • Hi Vladimir, `OPEN (79)` doesn't do anything functional in this case. I included it because I found that it demonstrates that if I open an arbitrary file handle (there isn't anything special about unit 79...it could be something else), then I get the fatal error with subsequent printing of quad precision numbers. I guess I should also have put a `CLOSE (79)` at the end, but that won't address the fatal error. – gmagoon Oct 26 '16 at 15:18
  • Just a quick update: A friend has been able to reproduce this problem on his Windows 10 system with a fresh install of 64-bit anaconda2 4.2.0, so that seems to confirm that it isn't something peculiar to my setup (like environment variables). I think I will bring this up on the anaconda forums to see if they have any ideas... – gmagoon Oct 31 '16 at 18:24

0 Answers0