https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Pavel Revak changed:
What|Removed |Added
CC||pavel.revak at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #29 from Jonathan Wakely ---
(In reply to Sasha B from comment #28)
> You can disregard whether the underlying type is fixed or not. So, GCC
> should not give a warning unless a bitfield containing Foo really is too
> small to hold a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Sasha B changed:
What|Removed |Added
CC||sashab at chromium dot org
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|jason at gcc dot gnu.org|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #25 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2013-02-16 01:07:16 UTC ---
Author: paolo
Date: Sat Feb 16 01:07:11 2013
New Revision: 196100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196100
Log:
/cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
11:26:16 UTC ---
The warning noticed by Jon seems a latent issue unrelated to bitfields and due
to the fact to for scoped enums, the underlying type, if not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
11:32:15 UTC ---
Or maybe it should *always* run, if the point is diagnostics: after all even if
the type is fixed why not adding to its representation the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
11:36:56 UTC ---
For example, consider this variant of the PR53661 situation:
enum class Code {
SUCCESS = 0
};
Code a;
short r[] = {a};
we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
11:46:46 UTC ---
That narrowing warning seems right to me, the enum variable could have a value
out of range of short:
Code a = static_castCode(SHRT_MAX+1);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
11:50:43 UTC ---
The difference from PR 53661 is that the underlying type of a scoped
enumeration is fixed, so its values are the values of (in this case) int. In PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:00:17 UTC ---
But something still seems wrong to me. Why warning depending on whether 'class'
is there for the following:
enum /*class*/ Code {
SUCCESS =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:05:21 UTC ---
Anyway, the latent issue is of course with fixed underlying types: if in that
case we don't care about warning more, this issue is already fixed,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:22:49 UTC ---
And to further clarify wrt your specific Comment 11, Jon, for:
#include limits.h
enum Code {
SUCCESS = 0
};
Code a =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
12:43:37 UTC ---
(In reply to comment #15)
we *error* out anyway, isn't that we are only emitting a warning and only when
we are assigning the SHRT_MAX + 1.
But
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|paolo.carlini at oracle dot |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
12:56:34 UTC ---
Clang doesn't warn for the code in comment 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
13:00:08 UTC ---
Well, then we should double check whether it warns at all when bitfields are
not involved, because I don't see anything bitfield-specific about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
13:27:45 UTC ---
Uhm, actually, when the underlying type is unscoped and we already accept the
code, we warn exactly in the same way. I'm not sure if this is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
13:39:17 UTC ---
I mean, with the grokbitfield tweak we obtain a behavior for Comment #1 which
in terms of warnings it's just a variant of Comment #13: if we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
14:00:37 UTC ---
Patchlet in Comment #6 passes testing for me.
As I tried clumsily to explain, I don't think it's consistent to avoid the
warning for Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
14:40:20 UTC ---
I think naming the warning would make sense, so it can be disabled by people
who want to use scoped enums with bit-fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-19
11:47:20 UTC ---
(In reply to comment #4)
Is this bug planned to be fixed in future?
Yes, of course. It's a bug.
Can I help in any way to do that?
Sure, you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-19
11:52:38 UTC ---
The check is for an unscoped enumeration type which does seem intentional.
This change allows the example to compile:
--- cp/decl2.c.orig
сообщение---
От: redi at gcc dot gnu.org
Отпр.: 19.11.2012, 15:47
Кому: volo...@netfolder.ru
Тема: [Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-19
11:47
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #2 from Vladimir volodya at netfolder dot ru 2012-11-19 05:47:19
UTC ---
What does 'rejects-valid' keywords mean?
18.11.2012 22:05 пользователь redi at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org написал:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-11-19 07:26:11 UTC ---
(In reply to comment #2)
What does 'rejects-valid' keywords mean?
It means that the compiler rejects valid code, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #4 from Vladimir volodya at netfolder dot ru 2012-11-19 07:56:26
UTC ---
Sorry for stupid questions :)
Is this bug planned to be fixed in future?
Can I help in any way to do that?
2012/11/19 daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
33 matches
Mail list logo
