Why exempt GIMPLE_TRY? It suppresses the warning in cases like:
switch (i) {
try { } catch (...) { }
case 1: ;
}
(If excluding GIMPLE_TRY is unavoidable, it might be worthwhile
to add a comment to the code, and perhaps also mention it in
the documentation to preempt bug reports by nitpickers like me ;)
I think I added that so that we do not warn on
switch (i)
{
int A[3];
default:
break;
}
because at the gimple level that looks like
{
int A[3];
try
{
<D.1751>:
goto <D.1752>;
}
finally
{
A = {CLOBBER};
}
}
I see. Thanks for clarifying that. No warning on a declaration
alone makes sense in the case above but it has the unfortunate
effect of suppressing the warning when the declaration is followed
by a statement, such as in:
void f (int*, int);
void g (int i)
{
switch (i) {
int a [3];
memset (a, 0, sizeof a);
default:
f (a, 3);
}
}
Another problem with try/finally is that it doesn't have a location
so we'd jsut print useless
cc1: warning: statement will never be executed [-Wswitch-unreachable]
That's too bad. I would expect statements following a declaration
to be almost as common as statements alone, especially in C where
this style of initializing local variables is idiomatic.
(I realize this might be outside the scope of the feature request
and starting to creep into the -Wunreachable-code territory.)
This really sounds like the old -Wunreachable stuff and I don't think
it's limited to switches as this warning is. Nowadays we have stuff
like gimple_stmt_may_fallthru so maybe that could be useful, but I'm
not about to plunge into this mess anytime soon ;).
Understood. It was just an observation that although ideally
the warning would make use of optimizations like VRP, it seems
that it could be made more useful even without it if it could
be taught to diagnose statements after unconditional breaks.
But I'm sure even that wouldn't be trivial.
Martin
