[Bug c++/53479] New: Control flow analysis too alarming with switch over an enum class

[Bug c++/53479] New: Control flow analysis too alarming with switch over an enum class

[0xd34df00d at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

             Bug #: 53479
           Summary: Control flow analysis too alarming with switch over an
                    enum class
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: 0xd34df00d@gmail.com


Created attachment 27492
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27492
A very simple testcase

If a non-void function consists of a switch over a variable of an enum class,
and all possible values of the enum class are listed in the cases, and each
case ends with a return, gcc 4.6 and later still emits a "control reaches end
of non-void function" warning. gcc 4.5 and earlier don't exhibit such behavior
(as well as clang, if that matters). See the attached file for an example.

While this is a somewhat reasonable behavior for switches over a plain enum, I
doubt it is OK to emit this warning, at least, with such a generic option as
-Wreturn-type. If neither case succeeds, then you have had an UB somewhere in
your code previously, but I doubt it's good to warn the user in the switch.

Moreover, adding a 'default' clause allows to shoot yourself in the foot later
when adding one more field in the enum — the compiler won't warn you that you
didn't check it. Adding a dummy return after the switch seems more like a
kludge.

If there are strong considerations for this warning in this case, I suggest
moving it to a separate warning class, like -Wreturn-enum-class or something
like that. This way those who don't need this check will be able to disable it
without hurting other cases where it's useful for them.

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-05-24 19:57:19 UTC ---
  Foo f = Foo(2);
  assert( DoFoo( f ) );

Undefined behaviour.

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[0xd34df00d at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #2 from Georg Rudoy <0xd34df00d at gmail dot com> 2012-05-24 20:04:56 UTC ---
(In reply to comment #1)
>   Foo f = Foo(2);
>   assert( DoFoo( f ) );
> 
> Undefined behaviour.

Yes, it is. And isn't it happening at the point of cast of an integer to the
enum class type?

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-05-24 20:21:57 UTC ---
No, there's nothing wrong with the cast.

A scoped enumeration type without an explicitly-specified underlying type has a
fixed underlying type of int, so the values of the enumeration type are the
values of int.

Your switch doesn't handle all values, so control can flow off the end of the
function, so the warning is correct.

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 19:11:20 UTC ---
Closing.