stdlib
stdlib copied to clipboard
fortran-lang
Fix conversion warnings
What do you think about these changes?
pro
fixes 12 warnings (the remaining 12 warnings should be easy to fix, too), which are ~ 60 lines to stderr
contra complexity of code (readability, maintainability, etc.)
Maybe there are better options to fix the warnings, please let me know.
Obviously this is a subjective judgement. My feeling is that, if the original code is legal, then the extra code complexity isn't worth it.
It would be ideal if were compiler options to turn off this kind of warning. But I don't know of any.
It would be ideal if were compiler options to turn off this kind of warning. But I don't know of any.
Usually it is the other way around: You can turn these warnings on with compiler options. Build systems tend to activate every warning available, because these warnings are useful (in general).
Yes, I think for this reason gfortran supports turning warnings off, like (-Wno-implicit) as well as on (-Wimplicit). So you can use -Wall and just silence a few of them.
It would be ideal if were compiler options to turn off this kind of warning. But I don't know of any.
We are getting a lot of false-positive and spurious warning from our current CMake setup. See https://github.com/fortran-lang/stdlib/issues/387 for further details.
We are getting a lot of false-positive and spurious warning from our current CMake setup. See #387 for further details.
Are those conversion warnings I fixed really false-positive? There are implicit conversions happening, so I think these are true-positive warnings. The question is, should we:
- Make the conversions explicit (verbose & complex code)
- Hide all conversion warnings (might hide useful warnings)
- Leave it as is (very verbose output, might also hide useful warnings)
We are using -Wconversion-extra which basically flags every conversion even if it is safe to use.
https://github.com/fortran-lang/stdlib/blob/8bfcdf9fdf8d3d897eee76512ba5083ecab29f96/CMakeLists.txt#L27
Okay, so do we want to leave the code as is and simply ignore the warnings?
My suggestion would be to check our compiler warning options first and trim those down to the useful ones. Once we get rid of the 90% false positives, we fix the remaining warnings.
I did a quick test if we can leave out the kind= arguments, because this would make the code a little more readable. Unfortunately this doesn't solves the Conversion from COMPLEX(4) to COMPLEX(16) warnings. But maybe this will be an useful option with a different set of compiler flags.
Most of them are due to specific compiler flags. I would first remove the useless ones, and then check the remaining warnings.
My suggestion would be to check our compiler warning options first and trim those down to the useful ones. Once we get rid of the 90% false positives, we fix the remaining warnings.
I agree with this. The next step would be to open a bug report with the compiler(s) that should not report false positives obfuscating the useful warnings. I don't think that we should bend stdlib to the needs of the compiler(s).
