* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
@ 2021-11-24 19:06 ` egallager at gcc dot gnu.org
2021-11-24 19:07 ` egallager at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-11-24 19:06 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
2021-11-24 19:06 ` [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
@ 2021-11-24 19:07 ` egallager at gcc dot gnu.org
2021-11-29 14:04 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-11-24 19:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
2021-11-24 19:06 ` [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
2021-11-24 19:07 ` egallager at gcc dot gnu.org
@ 2021-11-29 14:04 ` rguenth at gcc dot gnu.org
2021-11-29 14:10 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-29 14:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-11-29 14:04 ` rguenth at gcc dot gnu.org
@ 2021-11-29 14:10 ` rguenth at gcc dot gnu.org
2021-11-30 5:20 ` egallager at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-29 14:10 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-11-29 14:10 ` rguenth at gcc dot gnu.org
@ 2021-11-30 5:20 ` egallager at gcc dot gnu.org
2021-11-30 8:12 ` rguenther at suse dot de
` (3 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-11-30 5:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-11-30 5:20 ` egallager at gcc dot gnu.org
@ 2021-11-30 8:12 ` rguenther at suse dot de
2022-01-20 18:48 ` dcb314 at hotmail dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: rguenther at suse dot de @ 2021-11-30 8:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2021-11-30 8:12 ` rguenther at suse dot de
@ 2022-01-20 18:48 ` dcb314 at hotmail dot com
2022-01-20 18:51 ` dcb314 at hotmail dot com
2022-01-22 21:27 ` egallager at gcc dot gnu.org
8 siblings, 0 replies; 9+ messages in thread
From: dcb314 at hotmail dot com @ 2022-01-20 18:48 UTC (permalink / raw)
To: gcc-bugs
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)
^
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2022-01-20 18:48 ` dcb314 at hotmail dot com
@ 2022-01-20 18:51 ` dcb314 at hotmail dot com
2022-01-22 21:27 ` egallager at gcc dot gnu.org
8 siblings, 0 replies; 9+ messages in thread
From: dcb314 at hotmail dot com @ 2022-01-20 18:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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)
[not found] <bug-92479-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2022-01-20 18:51 ` dcb314 at hotmail dot com
@ 2022-01-22 21:27 ` egallager at gcc dot gnu.org
8 siblings, 0 replies; 9+ messages in thread
From: egallager at gcc dot gnu.org @ 2022-01-22 21:27 UTC (permalink / raw)
To: gcc-bugs
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"
^ permalink raw reply [flat|nested] 9+ messages in thread