Version: 1.0.2 [Maybe]
Hope that GCC can optimize out these redundant set operations.
Most of these warnings are due to const. Besides, there are several caused by volatile.
Why bother to check if addresses of variables are NULL?
Example:
N_LIB_PRIVATE N_NOINLINE(void, raiseEIO__ZYk14k3sVNZUIjJjtqzFZQ)(NimStringDesc* msg) __attribute__((noreturn));
...
N_LIB_PRIVATE N_NOINLINE(void, raiseEIO__ZYk14k3sVNZUIjJjtqzFZQ)(NimStringDesc* msg) {
....
raiseExceptionEx((Exception*)eX60gensym125424_, "IOError", "raiseEIO", "...\\lib\\system\\io.nim", 129);
popFrame();
}
For these warnings, I think that at least one of the following is wrong:
wchar_t is short unsigned int, not short int. IMHO, these four are actually ERRORS.
IMHO, these four are actually ERRORS.
Cool but in GCC's opinion, these are not. They are warnings. ;-)
One can only help you out after you think that you need to be helped out.
Regarding these warnings, it is more import to have a proper altitude towards them than to fix them. I am already helping on this.
Stop trying to force Nim to protect against C semantics.
GCC provides warnings to the user based on the assumption that they are writing C code by hand.
There is no expectation that Nim produces "human readable" or clean C code.
There are many things that I would not write by hand in C, but I am perfectly fine with generated code doing the same thing.
For example:
Why bother to check if addresses of variables are NULL?
Because Nim does prevent this, at a higher level
C code optimizes out checks in the assembly code that it can prove are unnecessary. Similarly, Nim will not include extra checks in C code that it can prove are unnecessary. Nim has no way to tell GCC this is the case, so GCC gives warnings.
It seems to me that your real problem is that you don't trust the Nim compiler.
Furthermore, If these are causing real issues, we await github bug reports showing a reproduction, or better yet, a PR that fixes these issues.
If you are just blindly running GCC with -wall, you aren't helping, you are just trolling.
I can understand foldl. When a compiler emits warnings, it could be because there's a possibility of a bug from the programmer in the code or another reason like "optimization in code generation not possible" because of something in the code. That's not an error, but that's a message that the compiler author emits to the programmer about something that he feels important but not critical.
Faced to these different types of warnings, the programmer should do two things:
Disabling all warnings as a whole without trying to understand why they appear is like not trusting the compiler author, being Nim or GCC. Like rayman22201 said, you must trust that Nim is generating efficient C code and issuing reasonable warnings, just like you must trust GCC is generating efficient binary code with reasonable warnings. Silencing blindly all warnings, either Nim's or GCC's, is like closing one eye because using one is enough to see...