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@xxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
