https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #24 from Jonathan Wakely ---
It's at https://gcc.gnu.org/wiki/VerboseDiagnostics#enum_switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #23 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #8)
>
> Perhaps I should add an entry to the FAQ summarizing the above (anyone feel
> free to beat me to it...)
The "Commonly-reported Non-bugs" page would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #22 from Andrew Pinski ---
*** Bug 93968 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Andrew Pinski changed:
What|Removed |Added
CC||gcc at cookiesoft dot de
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Andrew Pinski changed:
What|Removed |Added
CC||yuri at tsoft dot com
--- Comment #20 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #19 from DB ---
just for anyone finding this later, note this has been raised at the level of
the C++ Standard - http://wg21.link/p0375r0 - with the conclusion being:
> EWG pointed out that most enumerations are exhaustive, and
> we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #18 from DB ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to DB from comment #12)
> > (In reply to Jonathan Wakely from comment #11)
> > > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #17 from Jonathan Wakely ---
(In reply to DB from comment #12)
> (In reply to Jonathan Wakely from comment #11)
> > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> > -fstrict-enums tells the compiler it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #16 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #14)
> (In reply to Manuel López-Ibáñez from comment #9)
> > In summary, neither adding 'default' or 'return' are recommended to silence
> > this warning if you thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #15 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Eric Gallager from comment #6)
> > This should probably depend on the -fstrict-enums flag, as that controls
> > whether enums can have any value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #14 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #9)
> In summary, neither adding 'default' or 'return' are recommended to silence
> this warning if you think the warning is wrong. If you think the warning
> wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to DB from comment #10)
> Yeah, I've since thought of using abort(), which as you say, silences the
> warning - and indicates with sufficient strength that this shouldn't happen.
> assert() i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #12 from DB ---
(In reply to Jonathan Wakely from comment #11)
> Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> -fstrict-enums tells the compiler it will never have a value outside that
> range. It does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #11 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #6)
> This should probably depend on the -fstrict-enums flag, as that controls
> whether enums can have any value or just those values that are enumerated.
No, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #10 from DB ---
(In reply to Manuel López-Ibáñez from comment #8)
Thanks for the thoughts!
> Those "artificial kludges" not only silence the warning, but also make the
> code more readable and help the optimizer. A call to abort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #9 from Manuel López-Ibáñez ---
In summary, neither adding 'default' or 'return' are recommended to silence
this warning if you think the warning is wrong. If you think the warning will
always be wrong, use __builtin_unreachable(). If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #7 from DB ---
Interesting switch, thanks - doesn't make any difference to warnings at the
moment, though.
But it hits on what I'm going for: ensuring the compiler that I'll only use
named enumerator values. Ideally though, the Stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #5 from DB ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #3 from Jonathan Wakely 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 enumerati
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #1 from Jonathan Wakely 2012-05-24
19:57:19 UTC ---
Foo f = Foo(2);
assert( DoFoo( f ) );
Undefined behaviour.
24 matches
Mail list logo
