https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Jakub Jelinek changed:
What|Removed |Added
CC||ago at gentoo dot org
--- Comment #18 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #16 from Jonathan Wakely ---
Author: redi
Date: Wed Nov 25 16:11:40 2015
New Revision: 230884
URL: https://gcc.gnu.org/viewcvs?rev=230884&root=gcc&view=rev
Log:
Extend valid values of iostream bitmask types
Backport from mainline
20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #15 from Jonathan Wakely ---
Fixed on trunk, probably worth backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #14 from Jonathan Wakely ---
Author: redi
Date: Thu Nov 12 17:08:42 2015
New Revision: 230267
URL: https://gcc.gnu.org/viewcvs?rev=230267&root=gcc&view=rev
Log:
Extend valid values of iostream bitmask types
PR libstdc++/5615
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #13 from Jonathan Wakely ---
N.B. we could also get rid of the _S_ios_xxx_end enumerators, but that would
break any code which (foolishly) refers to them, e.g. to suppress Clang's
-Wswitch warnings.
My suggestion assumes that __INT_M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #12 from Jonathan Wakely ---
Richard's patch changes the values returned by operator~ which is not
desirable.
To fix the underlying type to int in C++03 (so that all values of int will be
valid values of the enumeration type) we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #11 from Jonathan Wakely ---
Now that sanitisers are complaining about this we should really fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Markus Trippelsdorf changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #9 from Paolo Carlini 2013-02-07
11:50:03 UTC ---
Sure, sure. If we really want to support -fstrict-enums, I'm afraid we are
going to open a big can of worms... Still, are you sure it causes problems
*here*? I'm asking because
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #8 from Jonathan Wakely 2013-02-07
11:39:31 UTC ---
I think since 4.6 the default behaviour (i.e. without -fstrict-enums) is safe.
With -fstrict-enums (or in releases before 4.6) the optimisers can assume that
no invalid valu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #7 from Paolo Carlini 2013-02-07
11:22:32 UTC ---
We should double check but I'm pretty sure that *in practice* *for GCC* things
are Ok, because the sizeof of these enums is 4 (and in practice the systems we
support have sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #6 from Paolo Carlini 2013-02-06
16:40:09 UTC ---
Oh, I was missing that, thanks. Now, I don't know if we should really try to
fix this now after so many years. I'm tempted to just leave it alone until we
break the ABI, unless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #5 from Jonathan Wakely 2013-02-06
15:59:51 UTC ---
[dcl.enum]/7 "For an enumeration whose underlying type is fixed, the values of
the enumeration are the values of the underlying type."
Because the underlying type in 17.5.2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #4 from Paolo Carlini 2013-02-06
15:29:38 UTC ---
I'm wondering: before doing anything in v3, is this a C++11 issue? Because in
17.5.2.1.3 I see a fixed underlying type but otherwise I see exactly
~static_cast(X) like in v3?!?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Paolo Carlini changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Paolo Carlini changed:
What|Removed |Added
CC||bkoz at redhat dot com
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
18 matches
Mail list logo
