]JOSS review] Chombo compilation error
Issue #4
resolved
while building Chombo, I run into:
f/3d.Linux.64.g++.gfortran.OPT/CFLeastSquares.f:148:31:
126 | & nnbrs, xpowc, nnbrs, (0.0d0), ata, npwrs)
| 2
......
148 | & npwrs, xpowc, nnbrs,0, coeffs, npwrs)
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
f/3d.Linux.64.g++.gfortran.OPT/CFLeastSquares.f:161:33:
126 | & nnbrs, xpowc, nnbrs, (0.0d0), ata, npwrs)
| 2
......
161 | & nfine, coeffs, npwrs, 0, mat, nfine)
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
I am using gfortran 11.2.1 on Fedora Linux 34.
Comments (6)
-
-
reporter
okay, it is clearly a bug, maybe it happens to work for some compilers, but I don’t think we should rely on it. Do you want me to do a PR replacing it with
zero?Otherwise, I think you should update the dependencies to make it explicit that only GCC <= 10 works.
-
Please try putting a zero. If it requires too many changes to fix, we can add a note to the dependencies.
-
reporter
I did. The PR I filed fixes the compilation for me.
-
reporter
-
- changed status to resolved
- Log in to comment
This is a Chombo issue. Ideally, Chombo would be updated to work with more modern compilers, however we do not manage this package. After gcc10, stricter type-checking was employed. This problem can be fixed in two ways: you can either add a compiler flag to convert this "error" into a mere warning, since it isn't really that serious, or else you can update the "0" in the call to Lapack's dgemm to the more appropriate value for the expected data type, which is "0.d0" as in the first line of each error message. The best way to do that is to replace "0" with "zero", which will get replaced during the pre-processing step.