Bug 79959 - -Wimplicit-fallthrough doesn't recognize some more complex exit cases
Summary: -Wimplicit-fallthrough doesn't recognize some more complex exit cases
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 7.0.1
: P3 normal
Target Milestone: ---
Assignee: Marek Polacek
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2017-03-08 14:48 UTC by Peter Eisentraut
Modified: 2021-09-12 08:39 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-07-31 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Eisentraut 2017-03-08 14:48:01 UTC
gcc-7 (Homebrew GCC 7-20170305_1) 7.0.1 20170305 (experimental)

Code:

#include <stdlib.h>

int
main(int argc, char **argv)
{
	switch (argc)
	{
	case 1:
		do { if (__builtin_constant_p(20) && (20) >= 20) abort(); } while(0);
	default:
		return 0;
	}
}

gcc-7 -Wimplicit-fallthrough -O2 -c test.c
test.c: In function 'main':
test.c:9:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
   do { if (__builtin_constant_p(20) && (20) >= 20) abort(); } while(0);

I would expect no warning here.

This concoction is a macro expansion that intends to communicate "noreturn" based on some constant argument value, and that generally works well for avoiding uninitialized variable warnings and things like that, so the control flow analysis is smart enough to recognize that this is an unconditional exit.  But the fallthrough analysis doesn't appear to be that smart.  It only detects a plain abort() or something like that.
Comment 1 Eric Gallager 2017-07-31 17:59:50 UTC
Confirmed that gcc warns.
Comment 2 Marek Polacek 2017-08-03 13:18:44 UTC
Should be possible to fix this.  Mine.
Comment 3 Eric Gallager 2018-08-03 02:14:17 UTC
(In reply to Marek Polacek from comment #2)
> Should be possible to fix this.  Mine.

For gcc 9?
Comment 4 Eric Gallager 2019-08-05 05:07:50 UTC
(In reply to Eric Gallager from comment #3)
> (In reply to Marek Polacek from comment #2)
> > Should be possible to fix this.  Mine.
> 
> For gcc 9?

...er, 10 now, I guess?