Re: gcc warn unreached else {}

[Xi Ruoyao <xry111@mengyan1223.wang>]

Sorry.  Forgot to CC the list.

On 2020-07-09 23:44 +0800, Xi Ruoyao wrote:
> On 2020-07-09 16:15 +0100, Jonny Grant wrote:
> > On 09/07/2020 16:00, Xi Ruoyao wrote:
> > > On 2020-07-09 10:45 +0100, Jonny Grant wrote:
> > > > Hello!
> > > > 
> > > > There is an example below, (my code is not like this example below). I'm
> > > > reporting a possible issue, and asking if there is a way to detect it in
> > > > code
> > > > bases. If it's a real issue I can file a bug report on Bugzilla.
> > > > 
> > > > Can gcc warn where code will not get to the 'return 3;' below?
> > > > 
> > > > Cheers, Jonny
> > > > 
> > > > 
> > > > int main(void)
> > > > {
> > > >     const int i = 1;
> > > >     if(1 == i)
> > > >     {
> > > >         return 1;
> > > >     }
> > > >     else if(1 != i)
> > > >     {
> > > >         return 2;
> > > >     }
> > > >     else
> > > >     {
> > > >         return 3;
> > > >     }
> > > > }
> > > 
> > > Generally finding all the branches in a program impossible to be executed
> > > is
> > > unsolvable.  Even in a program without any loop it's still NP-hard.
> > > 
> > > For some "simple" cases maybe we can implement some heuristics, or use a
> > > brute
> > > force approach (as a part of -fanalyzer).  But I doubt if these simple
> > > cases
> > > are
> > > really useful.
> > 
> > Thank you for your reply.
> > Yes, it would be useful to see more warnings output.
> > 
> > I see this situation every few weeks in code bases upon manual review. The
> > simple case is where it is boolean as above, and is just values, and the
> > else
> > if() the inverse.
> > The compiler actually generated assembler that returns '1', so it did strip
> > out the unused branches.
> > 
> > As two side questions:
> > -- Is there anyway to see which branches are removed?
> 
> You can use -fdump-rtl-expand.  For the example in OP it says:
> 
> > try_optimize_cfg iteration 1
> > 
> > Merging block 3 into block 2...
> > Merged blocks 2 and 3.
> > Merged 2 and 3 without moving.
> > Removing jump 6.
> > Merging block 4 into block 2...
> > Merged blocks 2 and 4.
> > Merged 2 and 4 without moving.
> 
> It's really not human-readable, but it's just how the optimizer works.  It
> works
> on an already-abstract representation of the code which is quite different
> from
> the "original" human-readable C code.
> 
> Another issue is, in any "serious" software projects if we output all dead-
> code
> elimination as warnings, the false warnings will spam your terminal.
> 
> Chris Lattner discussed this issues in his [article][1].  Though he was
> talking
> about undefined behaviors, the rationale is exactly same for any dead code.
> 
> [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
> 
> > -- Is there anyway to force the compile to keep all branches? (even those it
> > believes will never be executed).
> 
> -O0.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University