Warnings in dead-code

[Matthieu 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)

[Gabriel 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?

[Matthieu 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.

[Gabriel 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.