[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #7 from Jonathan Wakely --- Right, and of course there are many -Wreturn-type cases where no switches or enums are involved at all. The warning is about the missing return from the end of the function, not about the switch that happens before that. Determining that the end of the function was reached because of a misunderstanding about how enumerations work (either in the standard, or in GCC without -fstrict-enums) is probably not easy.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #6 from Harald van Dijk ---
If the warning should mention -fstrict-enums, it should only do it in specific
cases:
enum E { A, B, C };
int h(E e) {
switch (e) {
case A: return 0;
case B: return 0;
case C: return 0;
}
}
will still trigger the warning even with -fstrict-enums because now (E)3 is
valid.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- Maybe the warning text should mention -fstrict-enums to make more people aware of it?
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from gnzlbg --- > That's true if you use -fstrict-enums, Wasn't aware of this. Thanks, closing as invalid.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #3 from Jonathan Wakely --- (In reply to gnzlbg from comment #2) > Until C++17, creating an enum value that's out-of-range of the enum was > unspecified behavior. In C++ standard >= 17 (e.g. -std=c++17), this became > undefined behavior. With GCC it depends on the -fstrict-enums option. > The only way in which "h(E e)" can fall of its end in C++>=17 is if the > program already had undefined behavior. That's true if you use -fstrict-enums, and if you do that, there's no warning. Without that option GCC does not treat (E)2 as undefined, and so it considers it possible for the function to be called with that value.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #2 from gnzlbg --- > in a call to f(-1) the function falls off the end, Indeed, thanks. Using <= in the condition removes the warning. > and ditto in a call to h ((enum E)2) Until C++17, creating an enum value that's out-of-range of the enum was unspecified behavior. In C++ standard >= 17 (e.g. -std=c++17), this became undefined behavior. So the warning should point at the place where this happens: (enum E)2. The only way in which "h(E e)" can fall of its end in C++>=17 is if the program already had undefined behavior.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Martin Sebor ---
[Please include the full command line and the full compiler output in bug
reports (as requested in https://gcc.gnu.org/bugs/#need). Links to third party
sites are not a substitute (they can go away and the compiler versions they use
can change).]
$ cat pr100700.c && gcc -S -xc++ pr100700.c
int f(unsigned i) {
if (i < unsigned(-1)) return i;
}
enum E { A, B };
int h (enum E e) {
switch (e) {
case A: return 0;
case B: return 0;
}
}
pr100700.c: In function ‘int f(unsigned int)’:
pr100700.c:4:1: warning: control reaches end of non-void function
[-Wreturn-type]
4 | }
| ^
pr100700.c: In function ‘int h(E)’:
pr100700.c:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
13 | }
| ^
In both examples the warning is strictly correct: in a call to f(-1) the
function falls off the end, and ditto in a call to h ((enum E)2). I could see
value in relaxing the warning for the enum case and issuing it only under some
stricter setting (say with -Wextra or under a new level), similarly to
-Wswitch-default. I think there already is a request along these lines.
