[PATCH] PR c/10175: Fix for -Wunreachable-code

[Roger Sayle]

Hi Mark,
> This looks dangerous to me on several counts:
>
> (1) The looking-for-labels code might be slow.

This doesn't actually slow down the compiler.  Previously, we'd
traverse the entire expression emitting RTL as we went, now we
just traverse the same RTL looking for labels.  So all the same
memory is touched.

In the common case, no label is found (for C/C++ these only
occur in the GCC extension that allows statements in expressions),
so typical we're saving by avoiding generating RTL.  Even in
the obscure cases where we find a label, walk_tree drops out
early, so even then there isn't much of a slow down.

Also notice that the code doesn't even use walk_tree_no_duplicates.
My timings showed that expressions are typically so small that there
is virtually no performance difference between using a hash-table and
without.  The overhead of creating and using hashtables was unmeasurably
the same as just traversing the expression (for an x86 full bootstrap).


> (2) If you now have a chain of statements A, B, C where (say) A is a
> DECL_STMT, B is a GOTO_STMT, and C is a end-of-scope SCOPE_STMT, you'll
> leave out C.  No good.

You'll also notice that SCOPE_STMTs are always expanded, so constructors
and destructors are alway emitted.  In addition to your case above, we
also have to consider jumping into a scope.


> (3) You're only doing this as code is expanded; it should really be done
> for all functions, including ones that aren't expanded.

This is no worse than the previous situation, where these errors were
generated in the RTL.  If the function wasn't expanded previously, we'd
never see the error.  Also remember that this feature wasn't present
in v2.9x and has never worked for single statements in v3.x.


I completely agree that this kind of functionality needs to be moved
closer to the front-ends.  You only need to look at the mess in
jump.c:never_reached_warning and emit-rtl.c:force_line_numbers that
is trying to track line numbers for unreachable code deep in RTL.

Even with my proposed scheme, there is a huge amount the front end
could do to make life easier.  For example, if the parser kept
track of whether a statement/expression contains an embedded label
and whether looping constructs contain continue/break statements.


I also won't argue that we should continue to track down where it
is that we're currently deleting dead-code without issuing a warning.
However, if we do use middle-end dead code elimination, it also needs
to generate warnings for the code that it suppresses.


Roger
--