Pelles V11 Warnings

[John Z]

Well I finally jumped into Pelles Version 11.  However like the old lady with the shoe who had so many children she did not know what to do, I've got so many new warnings it is overwhelming as I try to resolve each.

So here is the first warning which I find a bit weird.
warning #2242: Call to 'memset' removed.

I've got many of these.  Here is the case

Code: [Select]

wchar_t HR[10];     // 10 wide characters
memset(HR,0,10);  // fill 1st 10 bytes with 0 <- warning #2242: Call to 'memset' removed.
So ok you might question why I do it - but why is it wrong? 
Then there is this to add, and confound, When this is the code:

Code: [Select]

wchar_t HR[10];     // 10 wide characters
memset(HR,0,10);  // fill 1st 10 bytes with 0
memset(HR,0,10);  // fill 1st 10 bytes with 0There are NO warnings about removing memset .....

I'm attaching the simple as possible project as a zip.  It includes both cases above as well as
alternative &HR[0] trial.  Don't need to run anything just compile it.

Then  - is the compiler really removing the memset commands?

Better to understand than to just disable the warning IMO...

Thanks for any clarification,
John Z

[TimoVJL]

optimization can replace memset with inline code.

[frankie]

In V11 Pelle spent a lot of time and efforts to enhance the optimizations.

Well I finally jumped into Pelles Version 11.  However like the old lady with the shoe who had so many children she did not know what to do, I've got so many new warnings it is overwhelming as I try to resolve each.

So here is the first warning which I find a bit weird.
warning #2242: Call to 'memset' removed.

I've got many of these.  Here is the case

Code: [Select]

wchar_t HR[10];     // 10 wide characters
memset(HR,0,10);  // fill 1st 10 bytes with 0 <- warning #2242: Call to 'memset' removed.
So ok you might question why I do it - but why is it wrong? 

This is simple to understand, global variables are by default initialized to 0, so the call to memset is redundant and automatically removed. The warning is just informational (you are using level2 warnings).

Then there is this to add, and confound, When this is the code:

Code: [Select]

wchar_t HR[10];     // 10 wide characters
memset(HR,0,10);  // fill 1st 10 bytes with 0
memset(HR,0,10);  // fill 1st 10 bytes with 0There are NO warnings about removing memset .....

This behavior instead is difficult to understand, I can only suppose that the optimization, probably peephole optimization, stops at the 1st memset call?

[John Z]

Thanks frankie & TimoVJL,

This is simple to understand, global variables are by default initialized to 0, so the call to memset is redundant and automatically removed. The warning is just informational (you are using level2 warnings).

BUT these are not global variables as I understand it.  To demo that I put them also in a added procedure (other than MainDlgProc) just in case I'm missing something.  Same results.

Yes, you are correct, Level 2 I always try to resolve all warnings to improve my knowledge/skills.  Being a novice at Windows C programming it pays to be attentive to the warnings.

optimization can replace memset with inline code.

You are right I turned off optimizations and the warnings disappeared for all cases. - Interesting..... the process of optimizing is resulting in the warning, not the original source code.


Thanks John

[frankie]

This is simple to understand, global variables are by default initialized to 0, so the call to memset is redundant and automatically removed. The warning is just informational (you are using level2 warnings).

BUT these are not global variables as I understand it.  To demo that I put them also in a added procedure (other than MainDlgProc) just in case I'm missing something.  Same results.

Yes, you are correct, Level 2 I always try to resolve all warnings to improve my knowledge/skills.  Being a novice at Windows C programming it pays to be attentive to the warnings.

Yes you're right, and moreover they couldn't have been global because they were followed by code. I was wrong.
In any case the compiler always inlines the function I see, and if you compile with debug enabled the warnings automagically disappears...
It seems an informational message to tell you that a call is suppressed, useful in case of other function to know that eventual lateral effects are nulled, but probably spurious in this case.

[Pelle]

A part of the optimizer will attempt to remove "dead stores" to "memory", mainly to aggregates (array/struct) with it's address taken.
If the single use of such a local aggregate is to be cleared by memset(), this is pointless. The memset() and variable can be removed.
This is similar to initializing an array without using it, like:

Code: [Select]

char buf[80] = {0};The "dead store" removal will be the same, but you will get different warnings because the compiler inserted the memset() in the latter case.
If you have multiple uses of a local aggregate it's assumed you are doing something useful with it. The analyze (before removal) of multiple uses is a bit harder, and repeatedly clearing an aggregate without actually using it seems too stupid to waste much time on...

[John Z]

I understand.  I was evidentially doing added unneeded work in the compiler optimization analysis of the code.

To clarify further - in the 'real' code all of the variables are actually used, all of that code was just stripped out to just get the smallest code to investigate the warning.

The double memset was never done in the real code, just a curiosity (what would happen if) test case.

I appreciate everyone's inputs and comments!  Always more to learn, and depth to gain.

John Z