specfun.f doesn't compile with MinGW #3395

Closed
rgommers opened this Issue Feb 26, 2014 · 8 comments

Projects

None yet

4 participants

@rgommers
Member

Standard release build, MinGW 3.4.5 + Wine + Python 2.7:

Found executable C:\MinGW\bin\g77.exe
customize GnuFCompiler
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
customize GnuFCompiler using build_clib
building 'sc_specfun' library
compiling Fortran sources
Fortran f77 compiler: C:\MinGW\bin\g77.exe -g -Wall -fno-second-underscore -mno-cygwin -O3 -funroll-loops
compile options: '-IC:\Python27\lib\site-packages\numpy\core\include -c'
g77.exe:f77: scipy\special\specfun\specfun.f
scipy\special\specfun\specfun.f: In subroutine `eixz':
In file included from scipy\special\specfun\specfun.f:0:
scipy\special\specfun\specfun.f:5607: warning: unused variable 'imf'
scipy\special\specfun\specfun.f: In subroutine `chgm':
scipy\special\specfun\specfun.f:5728: 
                 CTA=CMPLX(TAR,TAI,8)
                     ^
Too many arguments passed to intrinsic `CMPLX' at (^)
scipy\special\specfun\specfun.f:5731: 
                 CTB=CMPLX(TBR,TBI,8)
                     ^
Too many arguments passed to intrinsic `CMPLX' at (^)
scipy\special\specfun\specfun.f:5735: 
                 CTBA=CMPLX(TBAR,TBAI,8)
                      ^
Too many arguments passed to intrinsic `CMPLX' at (^)
scipy\special\specfun\specfun.f: In subroutine `cchg':
scipy\special\specfun\specfun.f:6079: 
                    CG1=CMPLX(G1R,G1I,8)
                        ^
Too many arguments passed to intrinsic `CMPLX' at (^)
scipy\special\specfun\specfun.f:6082: 
                    CG2=CMPLX(G2R,G2I,8)
                        ^
Too many arguments passed to intrinsic `CMPLX' at (^)
scipy\special\specfun\specfun.f:6086: 
                    CG3=CMPLX(G3R,G3I,8)
                        ^
Too many arguments passed to intrinsic `CMPLX' at (^)
scipy\special\specfun\specfun.f: In subroutine `fcoef':
scipy\special\specfun\specfun.f:8714: warning:
              IF (JM+1.GT.251) GOTO 6
                                    1
scipy\special\specfun\specfun.f:8754: (continued):
    6         FNAN=DNAN()
    2
Reference to label at (1) is outside block containing definition at (2)
error: Command "C:\MinGW\bin\g77.exe -g -Wall -fno-second-underscore -mno-cygwin -O3 -funroll-loops -IC:\Python27\lib\site-packages\numpy\core\include -c -c scipy\special\specfun\specfun.f -o build\temp.win32-2.7\scipy\special\specfun\specfun.o" failed with exit status 1
@rgommers rgommers added this to the 0.14.0 milestone Feb 26, 2014
@rgommers
Member

Should really put "fix Windows build" in the next release schedule explicitly and take two weeks for it:(

@WarrenWeckesser
Member

Looks like the third argument to CMPLX is not standard Fortran 77 (http://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnc8/index.html). Perhaps CMPLX(a, b, 8) should be DCMPLX(a, b)?

@sturlamolden
Contributor

General comment: Never hard-code kind numbers. The value is compiler dependent. The kind-number must always be obtained with a call to selected_real_kind.

@sturlamolden
Contributor

DCMPLX would be correct Fortran 77. Three-argument version of cmplx is Fortran 90.

@WarrenWeckesser
Member

It looks like every occurrence of CMPLX in specfun.f should be changed to DCMPLX. They all have double precision arguments and assign the result to a complex*16 value.

I'll create a pull request, but I'm not set up to do a complete build of scipy with Fortran 77.

@WarrenWeckesser
Member

#3402 should fix the compilation error. I think the warning about the goto can be ignored; the code looks OK.

I've compiled specfun.f with g77 to verify that the error no longer occurs, but I haven't built scipy, or even just the special subpackage, with g77, so I haven't run the test suite with on a g77-based build. (The tests pass with gfortran.)

@pv
Member
pv commented Feb 27, 2014

gh-3402 merged

@pv pv closed this Feb 27, 2014
@sturlamolden
Contributor

COMPLEX*16 should be changed to DOUBLE COMPLEX because kind-numbers should never be hard-coded. Kind numbers as size in bytes is FORTRAN IV, and invalid for Fortran 77 and later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment