[PATCH][RFC] middle-end/46476 - resurrect -Wunreachable-code
Michael Matz
matz@suse.de
Thu Nov 25 13:19:21 GMT 2021
Hello,
On Thu, 25 Nov 2021, Richard Biener wrote:
> > Yes, that's definitely the case - I was too lazy to re-use the old
> > option name here. But I don't have a good name at hand, maybe clang
> > has an option covering the cases I'm thinking about.
As you asked: I already have difficulties to describe the exact semantics
of the warning in sentences, so I don't find a good name either :-)
> > Btw, the diagnostic spotted qsort_chk doing
> >
> > if (CMP (i1, i2))
> > break;
> > else if (CMP (i2, i1))
> > return ERR2 (i1, i2);
> >
> > where ERR2 expands to a call to a noreturn void "returning"
> > qsort_chk_error, so the 'return' stmt is not reachable. Not exactly
> > a bug but somewhat difficult to avoid the diagnostic for. I suppose
> > the pointless 'return' is to make it more visible that the loop
> > terminates here (albeit we don't return normally).
Tough one. You could also disable the warning when the fallthrough
doesn't exist because of a non-returning call. If it's supposed to find
obvious programming mistakes it might make sense to regard all function
calls the same, like they look, i.e. as function calls that can return.
Or it might make sense to not do that for programmers who happen to know
about non-returning functions. :-/
> It also finds this strange code in label_rtx_for_bb:
So the warning is definitely useful!
> indeed the loop looks pointless. Unless the DECL_NONLOCAL case was
> meant to continue;
It's like that since it was introduced in 2007. It's an invariant that
DECL_NONLOCAL labels are first in a BB and are not followed by normal
labels, so a 'continue' wouldn't change anything; the loop is useless.
Ciao,
Michael.
More information about the Gcc-patches
mailing list