1
  • Windows 7 64 bits
  • GNU Fortran (GCC) 4.7.0 20111220 (experimental) --> The MinGW version installed with Anaconda3/Miniconda3 64 bits.

Hi all,

I'm trying to compile some Fortran code to be used from Python using F2Py. The full project is Solcore, in case anyone is interested. In Linux and MacOS everything works fine, the problem comes with Windows. After some effort I've nailed down the problem to the quadruple precision variables of my Fortran code, which are not being treated properly.

A minimum example that works perfectly well in Linux/MacOS but not in Windows is:

program foo
  real*16 q, q2
  q = 20
  q2 = q+q
  print*, q, q2
end program foo

In Linux/MacOS this prints, as expected:

20.0000000000000000000000000000000000         40.0000000000000000000000000000000000

However, in Windows I get:

2.00000000000000000000000000000000000E+0001 1.68105157155604675313133890866087630E-4932

Keeping aside the scientific notation, clearly this is not what I expected. The same result appear any time I try to do an operation with quadruple precision variables and I cannot figure out way.

This is not the same error already pointed out with quadruple precision variables in Fortran and the MinGW version included in Anaconda.

Any suggestion will be more than welcome. Please, keep in mind that, ultimately I need to make this work with F2Py, and MinGW included in Anaconda is the only way I have found in the end to make it work after reading many instructions and tutorials. Therefore, I would prefer to stick to it, if possible.

Many thanks,

Diego

dalonsoa
  • 215
  • 3
  • 11
  • I have not been able to reproduce this problem. But would expect that quadruple precision might not be supported here. Could you include `USE ISO_FORTRAN_ENV` and printout the value of `REAL128`? If that is a non-negative number, try to use `REAL(KIND=REAL128)` instead of `REAL*16` – kvantour Jan 31 '18 at 11:56
  • print*,real(q,real64),real(q2,real64) – tim18 Jan 31 '18 at 12:04
  • As you probably require compatibility with Microsoft c_double so c_double might be preferred over real64, if you can switch from iso_fortran_env to iso_c_binding – tim18 Jan 31 '18 at 12:12
  • @kvantour, printing REAL128 produced the number 10. I tried to use that one, as you suggest, but the resulting variables have way less precision, equivalent to REAL*10. Since you have not been able to reproduce the problem, could you tell me exactly the details of your system and compiler, as well as the output of the test program? Many thanks! – dalonsoa Apr 09 '18 at 13:36
  • @tim18, the output of that command is 0 and 0 (with many decimal zeros in each case). Not sure what that means. – dalonsoa Apr 09 '18 at 13:44
  • @dalonsoa, yes I recently discovered that gfortran had a bug there that only got solved much later on. REAL128 was not linked to quadruple precision but to long double (80 bits) – kvantour Apr 09 '18 at 13:45

0 Answers0