[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tiagomacarios at gmail dot com

--- Comment #7 from Eric Gallager <egallager at gcc dot gnu.org> ---
*** Bug 98750 has been marked as a duplicate of this bug. ***

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
Richi is working on a revival of -Wunreachable-code, so I'm going to un-suspend
this, in case he wants to do this part, too.

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interestingly clang doesn't warn for

int main()
{
  for(int i = 1;; i++){
    if(0)
      {
        ++i;
        break;
      }
  }
}

which looks quite stupid (an empty stmt is OK though).  In fact diagnosing
that specifically a 'break' is not reachable and controlling that with its
own option looks bogus.

I'm going to re-interpret -Wunreachable-code-{return,break} to mean to
diagnose unreachable code _after_ a return stmt or a break stmt.  It really
looks like clang went out with a hammer, assigning a different option to
each diagnostic invocation with a different text ...

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

--- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> I'm going to re-interpret -Wunreachable-code-{return,break} to mean to
> diagnose unreachable code _after_ a return stmt or a break stmt.  It really
> looks like clang went out with a hammer, assigning a different option to
> each diagnostic invocation with a different text ...

I actually appreciate that about clang; additional warning flag granularity
helps to break warning-silencing tasks down in to more-easily manageable parts
when there are a lot of similar warnings. Sometimes I might want to only focus
on one while saving the other for later.

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 30 Nov 2021, egallager at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
> 
> --- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #9)
> > I'm going to re-interpret -Wunreachable-code-{return,break} to mean to
> > diagnose unreachable code _after_ a return stmt or a break stmt.  It really
> > looks like clang went out with a hammer, assigning a different option to
> > each diagnostic invocation with a different text ...
> 
> I actually appreciate that about clang; additional warning flag granularity
> helps to break warning-silencing tasks down in to more-easily manageable parts
> when there are a lot of similar warnings. Sometimes I might want to only focus
> on one while saving the other for later.

I see.  Just in this case the choice to differentiate seems silly.

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #12 from David Binderman <dcb314 at hotmail dot com> ---
Interestingly, both gcc and clang have nothing to say about this code:

extern void g( int);

void f( int a)
{
        if (a >= 0)
        {
                if (a < 0)
                {
                        g(a);
                }
        }
}

$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -Wunreachable-code
jan20e.cc
$

cppcheck finds the problem:

$ cppcheck --enable=all jan20e.cc
Checking jan20e.cc ...
jan20e.cc:10:9: warning: Opposite inner 'if' condition leads to a dead code
block. [oppositeInnerCondition]
  if (a < 0)
        ^
jan20e.cc:8:8: note: outer condition: a>=0
 if (a >= 0)
       ^

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

--- Comment #13 from David Binderman <dcb314 at hotmail dot com> ---
While there are no occurrences of this problem in the gcc source code,
I count six of them in the current Linux kernel source code (v5.16).

Which is more than I would have thought. So this problem does
occur in practice.

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479

--- Comment #14 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to David Binderman from comment #12)
> Interestingly, both gcc and clang have nothing to say about this code:
> 
> extern void g( int);
> 
> void f( int a)
> {
> 	if (a >= 0)
> 	{
> 		if (a < 0)
> 		{
> 			g(a);
> 		}
> 	}
> }
> 
> $ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -Wunreachable-code
> jan20e.cc
> $
> 
> cppcheck finds the problem:
> 
> $ cppcheck --enable=all jan20e.cc
> Checking jan20e.cc ...
> jan20e.cc:10:9: warning: Opposite inner 'if' condition leads to a dead code
> block. [oppositeInnerCondition]
>   if (a < 0)
>         ^
> jan20e.cc:8:8: note: outer condition: a>=0
>  if (a >= 0)
>        ^

That's bug 82100, which is already linked under "See Also"