Warnings in dead-code

[boutier]

Dead code may lead to that kind of Warning : dead-code.cpc:3: Warning: Body of function ret falls-through. Adding a return statement

Example of code :

/* dead-code.cpc */
int main()
{
    do {
        return 0;
    } while(0);
    /* dead-code : adding "return 0;" avoid the warning. */
}

(checked on Windows -- cygwin)

[kerneis]

On Fri, Aug 23, 2013 at 05:39:10AM -0700, Matthieu Boutier wrote:

/* dead-code.cpc */
int main()
{
    do {
        return 0;
    } while(0);
    /* dead-code : adding "return 0;" avoid the warning. */
}

It will be very hard to fix in general. CIL translates this loop to:

while(1) {
  return 0;
  break;
}

and then decides that it falls-through because it contains a break statement. It would be hard to do a complete dead-code analysis at that stage. However, assuming that the problem only happens in practice in the stupid "do ... while(0)" macro-magic case, I could avoid creating the while(1) in the first place. Do you have a concrete (real-world) example of where this happens?

[boutier]

Do you have a concrete (real-world) example of where this happens?

Yes and no :

runtime/cpc_io.cpc: cpc_write() /* windows version*/

In the repository version, the macros don't use the "do {…} while(0)" construct, but just "{…}" instead. I tried with "do {…} while()" when trying to fix a syntax error (for an unknown type), and remark that Warning.

I can let the "{…}", or add "return 0;". If the second case, am I right to think it will not create more functions after the CPS ? I think that after the goto translation, the "break" will be a "goto" in dead code, and so discarded. You confirm ?

Anyway, don't build a ugly hack to catch "do {…} while" cases as you proposed.

[kerneis]

I can let the "{…}", or add "return 0;". If the second case, am I right to

I would advice you to just keep the former, as long as your are careful and do not export the macro. It becomes important to protect your macros when they are used by external users.

think it will not create more functions after the CPS ? I think that after the goto translation, the "break" will be a "goto" in dead code, and so discarded. You confirm ?

It will not be discarded, but it will never be called in practice (and might even be discarded by gcc in fact).

However, the while(1) loop introduced by CIL will still be goto converted, at least if you have a cps call in it. Compare:

do { return 0; } while(0); /* no conversion, no overhead */
do { return 0; cpc_yield(); } while(0); /* CPS conversion, 1 cps-call of overhead */

So it's best to avoid such fake loops if they contain cps calls. Otherwise, it simply does not matter (except for the annoying warning, that you can silence by adding a return 0).

Anyway, don't build a ugly hack to catch "do {…} while" cases as you proposed.

It wouldn't be that ugly, in fact it might even make real-world programs cleaner (because, really, this do/while(0) hack is here for syntactic reasons, not control-flow ones). But it's not straightforward either, because I would need to check that the body of the loop does not contain break or labels, etc.