[PATCH][RFC] middle-end/46476 - resurrect -Wunreachable-code

Richard Biener rguenther@suse.de
Thu Nov 25 13:46:53 GMT 2021


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.


More information about the Gcc-patches mailing list