On Thu, 25 Nov 2021, Michael Matz wrote:
> 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 :-)
It diagnoses some cases of unreachable code so -Wunreachable-code sounded
like the obvious fit :P But names can create (wrong) expectation ...
clang has
-Wunreachable-code{,-aggressive,-break,-fallthrough,-loop-increment,-return}
but documentation is very sparse, -break and -return are what -aggressive
enables.
> > > 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!
Yep, also found some more real issues. But I'm not managing it
to get clean in a bootstrap due to some remaining issues with
early folding exposing unreachable code following gcc_assert()s
Richard.
