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 warningson 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#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.

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 wonder if removing-Wconversion-extra is a good trade-off here?

I did a quick test if we can leave out thekind= arguments, because this would make the code a little more readable. Unfortunately this doesn't solves theConversion 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).