This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/15330] inconsistent slicing on cast of int to enum
- From: "sebor at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 May 2004 21:46:39 -0000
- Subject: [Bug c++/15330] inconsistent slicing on cast of int to enum
- References: <20040506183922.15330.sebor@roguewave.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From sebor at roguewave dot com 2004-05-06 21:46 -------
Subject: Re: inconsistent slicing on cast of int to enum
bangerth at dealii dot org wrote:
> ------- Additional Comments From bangerth at dealii dot org 2004-05-06 21:31 -------
> So do I (and I'll take action :-)
>
> The enum is supposed to be represented in a bitfield that is just as large
> as to hold the biggest possible enum value. We shouldn't prohibit the
> compiler to not honor this information.
Does the compiler actually take advantage of this to implement some
useful optimization? If so, I agree with closing the issue as NAD.
(I would appreciate if you could explain what this optimization is).
Otherwise, i.e., if the change between 3.3 and 3.4 was accidental,
I consider it a regression, certainly in the quality of the
implementation of the compiler.
Martin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15330