Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix conversion warnings #536

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Carltoffel
Copy link
Member

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.

@Carltoffel Carltoffel changed the title Fix conversion warnings in logspace Fix conversion warnings Sep 20, 2021
@gareth-nx
Copy link
Contributor

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.

@Carltoffel
Copy link
Member Author

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).

@gareth-nx
Copy link
Contributor

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.

@awvwgk
Copy link
Member

awvwgk commented Sep 20, 2021

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.

@Carltoffel
Copy link
Member Author

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)

@awvwgk
Copy link
Member

awvwgk commented Sep 20, 2021

We are using -Wconversion-extra which basically flags every conversion even if it is safe to use.

add_compile_options(-Wconversion-extra)

@Carltoffel
Copy link
Member Author

Okay, so do we want to leave the code as is and simply ignore the warnings?

@awvwgk
Copy link
Member

awvwgk commented Sep 22, 2021

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.

@gareth-nx
Copy link
Contributor

I wonder if removing -Wconversion-extra is a good trade-off here?

@Carltoffel
Copy link
Member Author

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.

@jvdp1
Copy link
Member

jvdp1 commented Oct 2, 2021

Most of them are due to specific compiler flags. I would first remove the useless ones, and then check the remaining warnings.

@epagone
Copy link

epagone commented Oct 8, 2021

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants